Re: [Haskell-cafe] Mystery of an Eq instance

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.

I can imagine the following dialogue happening between His[1] Excellency, the Lord Haskell (if I am allowed to anthropomorphize it) and me: Me: "My Lord, I just used the (==) on floats and it gave me some unpleasant surprises." Lord Haskell: "You fool, why did you tested floats for equality? Don't you know a bit about floating points?" Me: "My Lord, I thought it'd be safe as it came with the typeclass guarantee you give us." Lord Haskell: "Look, you fool you scum you unenlightened filthy soul, yes I know I gave you that Eq instance for the floating point BUT nonetheless you should NOT have used it; NOW go enlighten yourself." Me: "My Lord, thank you for the enlightenment." I don't know how many people out there are being enlightened by His Excellency, the Lord Haskell, on floating point equality and other things. Yes, many a good old junkies, like the filthier kinkier C, were keen on enlightening people on such issues. But, see, C is meant to be used for such enlightenment. Although I am not an expert on floating point numbers, the paper is not surprising as I have learnt, at least some things given in the paper, the hard way by burning myself a couple of times because of the floating point thing while programming some things in the good old C. But even the Haskell tempted to define an Eq instance for that scary thing __that__ was a new enlightenment for me. Life is full of opportunities to enlighten yourself. That was also a reason before GHC 7.4 (Eq is no longer a superclass of Num). This seems a good step forward, removing the Eq instance altogether on floating point types would be much better; (unless as pointed out by Brandon, "you have a very clever representation that can store (floats) in terms of some operation like sin(x) or ln(x) (with infinite precision)") I know I might be wrong in expecting this change as it might break a lot of existing code. But why not daydream? [1] Please read His/Her Thanks and regards, -Damodar Kulkarni On Fri, Sep 20, 2013 at 10:04 PM, Stijn van Drongelen wrote:

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