[Haskell-cafe] Mystery of an Eq instance

[damodar kulkarni]

> 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 <rhymoid at gmail.com>wrote:

> 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/20130921/d8e2cfc2/attachment.htm>