[squeak-dev] Is there a better implementation of Floats?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Is there a better implementation of Floats?

Bernd Elkemann
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!


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Is there a better implementation of Floats?

Bert Freudenberg

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 -



Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Is there a better implementation of Floats?

cedreek
> > 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 -
>
>
>
>


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Is there a better implementation of Floats?

Nicolas Cellier-3
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


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Is there a better implementation of Floats?

Bernd Elkemann
> 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


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Is there a better implementation of Floats?

Paolo Bonzini-2
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

Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Is there a better implementation of Floats?

Nicolas Cellier-3
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