[Haskell-cafe] Mystery of an Eq instance

[Stijn van Drongelen]

On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni <kdamodar2000 at gmail.com>wrote:

> Ok, let's say it is the effect of truncation. But then how do you explain
> this?
>
> Prelude> sqrt 10.0 == 3.1622776601683795
> True
> Prelude> sqrt 10.0 == 3.1622776601683796
> True
>
>
Well, that's easy:

    λ: decodeFloat 3.1622776601683795
    (7120816245988179,-51)
    λ: decodeFloat 3.1622776601683796
    (7120816245988179,-51)

On my machine, they are equal. Note that ...4 and ...7 are also equal,
after they are truncated to fit in 53 (which is what `floatDigits 42.0`
tells me) bits (`floatRadix 42.0 == 2`).

Ok, again something like truncation or rounding seems at work but the
> precision rules the GHC is using seem to be elusive, to me.
>

It seems to me that you're not familiar with the intricacies of
floating-point arithmetic. You're not alone, it's one of the top questions
on StackOverflow.

Please find yourself a copy of "What Every Computer Scientist Should Know
About Floating-Point Arithmetic" by David Goldberg, and read it. It should
be very enlightening. It explains a bit about how IEEE754, pretty much the
golden standard for floating point math, defines these precision rules.

But more importantly, if one is advised NOT to test equality of two
> floating point values, what is the point in defining an Eq instance?
>

Although equality is defined in IEEE754, it's not extremely useful after
arithmetic (except perhaps for zero tests). Eq is a superclass of Ord,
however, which is vital to using floating point numbers.

Is the Eq instance there just to make __the floating point types__ members
> of the Num class?
>

That was also a reason before GHC 7.4 (Eq is no longer a superclass of Num).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130920/3fb0d26f/attachment.htm>