float & fraction equality bug

On 11/09/2017 06:15 AM, Tudor Girba wrote:

Hi,

I just stumbled across this bug related to the equality between fraction and float:

https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo

In essence, the problem can be seen that by doing this, you get a ZeroDivide:

x := 0.1.

y := (1/10).

x = y ifFalse: [ 1 / (x - y) ]

The issue seems to come from the Float being turned to a Fraction, rather than the Fraction being turned into a Float:

Fraction(Number)>>adaptToFloat: rcvr andCompare: selector 
"If I am involved in comparison with a Float, convert rcvr to a
Fraction. This way, no bit is lost and comparison is exact."

rcvr isFinite
ifFalse: [
selector == #= ifTrue: [^false].
selector == #~= ifTrue: [^true].
rcvr isNaN ifTrue: [^ false].
(selector = #< or: [selector = #'<='])
ifTrue: [^ rcvr positive not].
(selector = #> or: [selector = #'>='])
ifTrue: [^ rcvr positive].
^self error: 'unknow comparison selector'].

^ rcvr asTrueFraction perform: selector with: self

Even if the comment says that the comparison is exact, to me this is a bug because it seems to fail doing that. What do you think?

I think exact comparison is the best thing to do here (even though ANSI says otherwise). And an exact comparison will answer false, because there is no float that is exactly equal to 1/10 -- it is an infinitely repeating decimal in binary.

For consistency, though, it might be better to compute x - y by converting the Float to a Fraction rather than the other way around (though this would also contravene ANSI) since Fraction is the more general format (every Float can be represented exactly as a Fraction, but the reverse is not true).

Regards,
-Martin

According to IEEE 754, the base of Pharo Float, *finite* values shall behave like old plain arithmetic.

On 2017-11-09 15:36, Nicolas Cellier wrote:

Nope, not a bug.

If you use Float, then you have to know that (x -y) isZero and (x = y) are two different things.
Example; Float infinity

In your case you want to protect against (x-y) isZero, so just do that.

2017-11-09 15:15 GMT+01:00 Tudor Girba <[hidden email] <mailto:[hidden email]>>:

    Hi,

    I just stumbled across this bug related to the equality between
    fraction and float:
    https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo
    <https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo>

    In essence, the problem can be seen that by doing this, you get a
    ZeroDivide:
    x := 0.1.
    y := (1/10).
    x = y ifFalse: [ 1 / (x - y) ]

    The issue seems to come from the Float being turned to a Fraction,
    rather than the Fraction being turned into a Float:

    Fraction(Number)>>adaptToFloat: rcvr andCompare: selector
    "If I am involved in comparison with a Float, convert rcvr to a
    Fraction. This way, no bit is lost and comparison is exact."

    rcvr isFinite
    ifFalse: [
    selector == #= ifTrue: [^false].
    selector == #~= ifTrue: [^true].
    rcvr isNaN ifTrue: [^ false].
    (selector = #< or: [selector = #'<='])
    ifTrue: [^ rcvr positive not].
    (selector = #> or: [selector = #'>='])
    ifTrue: [^ rcvr positive].
    ^self error: 'unknow comparison selector'].

    ^ *rcvr asTrueFraction perform: selector with: self*

    Even if the comment says that the comparison is exact, to me this is
    a bug because it seems to fail doing that. What do you think?

    Cheers,
    Doru


    --
    www.tudorgirba.com <http://www.tudorgirba.com>
    www.feenk.com <http://www.feenk.com>

    "Problem solving should be focused on describing
    the problem in a way that makes the solution obvious."

Hi,

Thanks for the answer. The example I provided was for convenience.

I still do not understand why it is wrong to expect 0.1 = (1/10) to be true.

Doru

> On Nov 9, 2017, at 3:36 PM, Nicolas Cellier <[hidden email]> wrote:
>
> Nope, not a bug.
>
> If you use Float, then you have to know that (x -y) isZero and (x = y) are two different things.
> Example; Float infinity
>
> In your case you want to protect against (x-y) isZero, so just do that.
>
> 2017-11-09 15:15 GMT+01:00 Tudor Girba <[hidden email]>:
> Hi,
>
> I just stumbled across this bug related to the equality between fraction and float:
> https://pharo.fogbugz.com/f/cases/20488/x-y-iff-x-y-0-is-not-preserved-in-Pharo
>
> In essence, the problem can be seen that by doing this, you get a ZeroDivide:
> x := 0.1.
> y := (1/10).
> x = y ifFalse: [ 1 / (x - y) ]
>
> The issue seems to come from the Float being turned to a Fraction, rather than the Fraction being turned into a Float:
>
> Fraction(Number)>>adaptToFloat: rcvr andCompare: selector
>       "If I am involved in comparison with a Float, convert rcvr to a
>       Fraction. This way, no bit is lost and comparison is exact."
>
>       rcvr isFinite
>               ifFalse: [
>                       selector == #= ifTrue: [^false].
>                       selector == #~= ifTrue: [^true].
>                       rcvr isNaN ifTrue: [^ false].
>                       (selector = #< or: [selector = #'<='])
>                               ifTrue: [^ rcvr positive not].
>                       (selector = #> or: [selector = #'>='])
>                               ifTrue: [^ rcvr positive].
>                       ^self error: 'unknow comparison selector'].
>
>       ^ rcvr asTrueFraction perform: selector with: self
>
> Even if the comment says that the comparison is exact, to me this is a bug because it seems to fail doing that. What do you think?
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Problem solving should be focused on describing
> the problem in a way that makes the solution obvious."
>
>
>
>
>
>

--
www.tudorgirba.com
www.feenk.com

"We are all great at making mistakes."

On 2017-11-09 15:55, Nicolas Cellier wrote:

2017-11-09 15:48 GMT+01:00 Tudor Girba <[hidden email] <mailto:[hidden email]>>:

    Hi,

    Thanks for the answer. The example I provided was for convenience.

    I still do not understand why it is wrong to expect 0.1 = (1/10) to
    be true.

    Doru


Because there are infinitely many different Fraction that would be "equal" to 0.1 then.
The first effect is that you have

a = b
a = c
b < c

You are breaking the fact that you can sort these Numbers (are they Magnitude anymore?)
You are breaking the fact that you can mix these Numbers as Dictionary keys (sometimes the dictionary would have 2 elements, sometimes 3, unpredictably).

Fractions are not reliable keys anyway:
(Fraction numerator: 1 denominator: 3) = (Fraction numerator: 2 denominator: 6)
evaluates to true while
(Fraction numerator: 1 denominator: 3) hash = (Fraction numerator: 2 denominator: 6) hash
evaluates to false

On 2017-11-09 15:50, Nicolas Cellier wrote:

This is out of context.
There is no such thing as Fraction type covered by IEEE 754 standard.

Yes, I agree. But we should still strive to model arithmetic embracing the principle of least surprise. That's why in every arithmetic system I'm aware of (with the exception of very old CPUs dating back several decades), for finite x, y the
    x = y if and only if x - y = 0
property holds.

Let's put it in another perspective: what's the usefulness of having
    x = y
evaluate to false just to discover that
    x - y
evaluates to 0, or the other way round?

Anyway relying upon Float equality should allways be subject to extreme caution and examination

For example, what do you expect with plain old arithmetic in mind:

     a := 0.1.
     b := 0.3 - 0.2.
     a = b

This will lead to (a - b) reciprocal = 3.602879701896397e16
If it is in a Graphics context, I'm not sure that it's the expected scale...

a = b evaluates to false in this example, so no wonder (a - b) evaluates to a big number.

But the example is not plain old arithmetic.

Here, 0.1, 0.2, 0.3 are just a shorthands to say "the Floats closest to 0.1, 0.2, 0.3" (if implemented correctly, like in Pharo as it seems). Every user of Floats should be fully aware of the implicit loss of precision that using Floats entails.

So, using Floats to represent decimal numbers is the real culprit in this example, not the underlying Float arithmetic, which is very well defined from a mathematical point of view. In other words, using Floats to emulate decimal arithmetic will frustrate anybody because Floats work with limited precision binary arithmetic. Users wanting to engage in decimal arithmetic should simply not use Floats. (That's the reason for the addition of limited precision decimal arithmetic and numbers in the IEEE 754-2008 standard.)

That said, this does not mean we should give up useful properties like the one discussed above. Since we *can* ensure this property, we also should, in the spirit of the principle of least surprise.

What's problematic in Pharo is that comparison works in one way while subtraction works in another way but, mathematically, these operations are essentially the same. So let's be consistent.

In the case of mixed-mode Float/Fraction operations, I personally prefer reducing the Fraction to a Float because other commercial Smalltalk implementations do so, so there would be less pain porting code to Pharo, perhaps attracting more Smalltalkers to Pharo.

But the main point here, I repeat myself, is to be consistent and to have as much regularity as intrinsically possible.