[BUG] Inconsistent float soustraction

Hi,

I noticed in my image (damien last beta so 3.10 - windows XP and
Vista) that I have a strange bug when soustracting floats
successively. Here is how I reproduce it in a workspace:

1 - 0.2 -0.05 -0.3 = 0.45 "true"
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

or again:
1 - 0.1 = 0.9  true
1 - 0.1 - 0.1 = 0.8 true
1 - 0.1 - 0.1 - 0.1 = 0.7 false


Can somebody explain that or is it a bug ? I don't know yet if it's
specific to my image, so does other have the same behavior?
I can force the rounding of the result but find it strange.

Cédrick

This is not even squeak specific. Decimal floats not always can be represented precisely in binary form:

http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

2008/2/17, danil osipchuk <[hidden email]>:
> This is not even squeak specific. Decimal floats not always can be
> represented precisely in binary form:
>
> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
>
>
ok, thanks for the pointer :)
I'll cope with that...

Cédrick

Hi Cédrick,

        if you need to operate with exact precision just don't trust floats. Use ScaledDecimals instead. In Squeak ScaledDecimals are implemented with the fraction so it's matematically stronger than floats. Use floats at presentation or user interface time and evade them at domain model.

        cheers,

Sebastian Sastre


 

2008/2/17, danil osipchuk <[hidden email]>:
> This is not even squeak specific. Decimal floats not always can be
> represented precisely in binary form:
>
> http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems
>


> Hi Cédrick,
>
>         if you need to operate with exact precision just don't trust floats. Use ScaledDecimals instead. In Squeak ScaledDecimals are implemented with the fraction so it's matematically stronger than floats. Use floats at presentation or user interface time and evade them at domain model.
>
>         cheers,
>
> Sebastian Sastre

uhm ok, good to know.
Actually, it was just a test that failed so I was surprised.

I still find the result odd.

Seeing ScaledDecimal>>testConvertFromFloat, I'm wandering if it would
be better to have Float>>=   considering egality if the difference is
less than 1.0e-9.

<primitive: 47>
aNumber isNumber ifFalse: [^ false].
^ (aNumber asFloat - self) abs  <  1.0e-9

I would prefer having = working as I expect, even if it would be wrong
for smaller values than 1.0e-9. For strict egality, == can be used.

Is it possible to disable a primitive call like here (it's optimized no ?) ?

Anyway, thanks for your answers.

Cédrick

> aNumber isNumber ifFalse: [^ false].
> ^ (aNumber asFloat - self) abs  <  1.0e-9
>
> I would prefer having = working as I expect, even if it would be wrong
> for smaller values than 1.0e-9. For strict egality, == can be used.

No, you're just supposed to know it when you use floating-point math.
And even if you wanted to do it, you would probably look at relative
error rather than absolute error (i.e. (aNumber asFloat - self) abs /
(self abs min: aNumber asFloat abs) or something like that.

Paolo