[Pharo-dev] float & fraction equality bug

raffaello.giulietti at lifeware.ch raffaello.giulietti at lifeware.ch
Thu Nov 9 17:50:01 EST 2017

On 2017-11-09 22:11, Nicolas Cellier wrote:

>             Something like exact difference like Martin suggested, then
>             converting to nearest Float because result is inexact:
>                  ((1/10) - 0.1 asFraction) asFloat
>             This way, you would have a less surprising result in most cases.
>             But i could craft a fraction such that the difference
>             underflows, and the assertion a ~= b ==> (a - b) isZero not
>             would still not hold.
>             Is it really worth it?
>             Will it be adopted in other dialects?
>         As an alternative, the Float>>asFraction method could return the
>         Fraction with the smallest denominator that would convert to the
>         receiver by the Fraction>>asFloat method.
>         So, 0.1 asFraction would return 1/10 rather than the beefy
>         Fraction it currently returns. To return the beast, one would
>         have to intentionally invoke asExactFraction or something similar.
>         This might cause less surprising behavior. But I have to think more.
>     No the goal here was to have a non null difference because we need
>     to preserve inequality for other features.
>     Answering anything but a Float at a high computation price goes
>     against primary purpose of Float (speed, efficiency)
>     If that's what we want, then we shall not use Float in the first place.
>     That's why I don't believe in such proposal
>     The minimal Fraction algorithm is an intersting challenge though.
>     Not sure how to find it...

I'm thinking of a continuous fraction expansion of the exact fraction
until the partial fraction falls inside the rounding interval of the Float.

Heavy, but doable.

Not sure, however, if it always meets the stated criterion.

More information about the Pharo-dev mailing list