On Fri, Sep 20, 2013 at 6:17 PM, damodar kulkarni <kdamodar2000@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).