[Haskell-cafe] Mystery of an Eq instance

Stijn van Drongelen rhymoid at gmail.com
Fri Sep 20 18:34:04 CEST 2013

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
    λ: decodeFloat 3.1622776601683796

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>

More information about the Haskell-Cafe mailing list