Hi
i am very impressed by squeaks handling of large integers (LargePositiveInteger and resulting from that the Fraction-class). However i was disappointed about the small number of digits of Floats so my first question is: is there a possibility to increase it? the second thing is: i found these examples on the squeak newbee group. 1 - 0.2 -0.05 -0.3 -0.1= 0.35 "true" 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.25 "*****false*****" 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.24999999999999995 "true " and i add the following examples: 0.35 - 0.0 = 0.35 "true" 0.35 - 0.1 = 0.25 "false" Is there a better implementation of Floats? thanks in advance! |
On 09.04.2008, at 07:03, Bernd Elkemann wrote: > Hi > i am very impressed by squeaks handling of large integers > (LargePositiveInteger and resulting from that the Fraction-class). > However i was disappointed about the small number of digits of Floats > so my first question is: is there a possibility to increase it? > the second thing is: i found these examples on the squeak newbee > group. > 1 - 0.2 -0.05 -0.3 -0.1= 0.35 "true" > 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.25 "*****false*****" > 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.24999999999999995 "true " > and i add the following examples: > 0.35 - 0.0 = 0.35 "true" > 0.35 - 0.1 = 0.25 "false" This is an intrinsic property of Floats, not specific to Squeak. It's how floating point numbers work in your processor. Google "0.1 floating point" if you want to know more. > Is there a better implementation of Floats? Depending on your definition of "better" you might consider ScaledDecimals: 0.35s2 - 0.1s2 = 0.25s2 (in this example with 2 digits of precision) - Bert - |
> > 1 - 0.2 -0.05 -0.3 -0.1= 0.35 "true"
> > 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.25 "*****false*****" > > 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.24999999999999995 "true " > > and i add the following examples: > > 0.35 - 0.0 = 0.35 "true" > > 0.35 - 0.1 = 0.25 "false" There was an interesting discussion around this aspect of float recently after I noticed this results. http://lists.squeakfoundation.org/pipermail/beginners/2008-February/003816.html Cédrick > > > > This is an intrinsic property of Floats, not specific to Squeak. It's how > floating point numbers work in your processor. Google "0.1 floating point" > if you want to know more. > > > > Is there a better implementation of Floats? > > > > Depending on your definition of "better" you might consider ScaledDecimals: > > 0.35s2 - 0.1s2 = 0.25s2 > > (in this example with 2 digits of precision) > > - Bert - > > > > |
In reply to this post by Bert Freudenberg
Bert Freudenberg wrote:
> > On 09.04.2008, at 07:03, Bernd Elkemann wrote: >> Hi >> i am very impressed by squeaks handling of large integers >> (LargePositiveInteger and resulting from that the Fraction-class). >> However i was disappointed about the small number of digits of Floats >> so my first question is: is there a possibility to increase it? >> the second thing is: i found these examples on the squeak newbee group. >> 1 - 0.2 -0.05 -0.3 -0.1= 0.35 "true" >> 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.25 "*****false*****" >> 1 - 0.2 -0.05 -0.3 -0.1 - 0.10= 0.24999999999999995 "true " >> and i add the following examples: >> 0.35 - 0.0 = 0.35 "true" >> 0.35 - 0.1 = 0.25 "false" > > This is an intrinsic property of Floats, not specific to Squeak. It's > how floating point numbers work in your processor. Google "0.1 floating > point" if you want to know more. > >> Is there a better implementation of Floats? > > Depending on your definition of "better" you might consider ScaledDecimals: > > 0.35s2 - 0.1s2 = 0.25s2 > > (in this example with 2 digits of precision) > > - Bert - > > Yes, as Bert said, Floating point operations are inherently inexact, while arithmetic on LargeInteger and Fraction are exact. I'am personnaly in favour of answering false if the inexact floating point representation once converted to an exact one is not equal to the exact one. (1/3.0) asTrueFraction = (1/3) -> false. Current implementation is to answer true because the conversion is made toward inexact: (1/3.0) = (1/3) asFloat -> true. Some are more extremists and argue such equality betwen exact and inexact should ALWAYS return false. ScaledDecimal as suggested by Bert are just Fraction with a different method for printing (using an approximate decimal notation, beware, not rounded in Squeak but truncated to a fixed number of decimal places after the decimal point). If you really want Floating point operations (that is inexact) with more digits, I initiated the ArbitraryPrecisionFloat package at http://www.squeaksource.com/ArbitraryPrecisionFl/ . You can download it using Monticello or SqueakMap (better use Monticello, the SqueakMap will point on an old version). There are also other interesting work, MathMorph did have an AlgebraicNumber if I remember well. However, you have either to take an older squeak version, or wait for MathMorph to be ported in newer versions to try it. You now have enough refs to proceed by yourself... Cheers Nicolas |
> If you really want Floating point operations (that is inexact) with more
> digits, I initiated the ArbitraryPrecisionFloat package at > http://www.squeaksource.com/ArbitraryPrecisionFl/ . You can download it > using Monticello or SqueakMap (better use Monticello, the SqueakMap will > point on an old version). I think thats exactly what i need, thanks so much |
Bernd Elkemann wrote:
>> If you really want Floating point operations (that is inexact) with >> more digits, I initiated the ArbitraryPrecisionFloat package at >> http://www.squeaksource.com/ArbitraryPrecisionFl/ . You can download >> it using Monticello or SqueakMap (better use Monticello, the SqueakMap >> will point on an old version). > > I think thats exactly what i need, > thanks so much Actually I'm sure it is not. It will have exactly the same problems, they are less likely but cannot be magically solved: 0.1, 0.15, 0.2, 0.3 are anyway periodic numbers in base-2. Paolo |
Paolo Bonzini wrote:
> Bernd Elkemann wrote: >>> If you really want Floating point operations (that is inexact) with >>> more digits, I initiated the ArbitraryPrecisionFloat package at >>> http://www.squeaksource.com/ArbitraryPrecisionFl/ . You can download >>> it using Monticello or SqueakMap (better use Monticello, the >>> SqueakMap will point on an old version). >> >> I think thats exactly what i need, >> thanks so much > > Actually I'm sure it is not. It will have exactly the same problems, > they are less likely but cannot be magically solved: 0.1, 0.15, 0.2, 0.3 > are anyway periodic numbers in base-2. > > Paolo > > Absolutely right. Computing with excess precision and rounding result afterward is not guaranteed to work, compared to strict IEEE754, it only lowers probability of rounding error. ((0.35s2 asArbitraryPrecisionFloatNumBits: 69) - (0.1s2 asArbitraryPrecisionFloatNumBits: 69)) asFloat = 0.25 -> true. Some kind of emulation of what an extended precision Intel floating point register would do... Much slower, but totally portable and under the control of programmer. Of course, testing for strict equality after some inexact operations is certainly not a recommended practice, so the question was biased. We cannot infer further underlying intention of Bernd. Up to his responsibility. Nicolas |
Free forum by Nabble | Edit this page |