[Haskell-cafe] Mystery of an Eq instance

[Mike Meyer]

On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni <kdamodar2000 at gmail.com>
wrote:
> 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)")

Please don't. The problem isn't with the Eq instance. It does exactly
what it should - it tells you whether or not two floating point
objects are equal.

The problem is with floating point arithmetic in general. It doesn't
obey the laws of arithmetic as we learned them, so they don't behave
the way we expect. The single biggest gotcha is that two calculations
we expect to be equal often aren't. As a result of this, we warn
people not to do equality comparison on floats.

So people who don't understand that wind up asking "Why doesn't this
behave the way I expect?" Making floats not be an instance of Eq will
just cause those people to ask "Why can't I compare floats for
equality?". This will lead to pretty much the same explanation. It
will also mean that people who know what they're doing who want to do
so will have to write their own code to do it.

It also won't solve the *other* problems you run into with floating
point numbers, like unexpected zero values from the hole around zero.

Given that we have both Data.Ratio and Data.Decimal, I would argue
that removing floating point types would be better than making them
not be an instance of Eq.

It might be interesting to try and create a floating-point Numeric
type that included error information. But I'm not sure there's a good
value for the expression 1.0±0.1 < 0.9±0.1.

Note that Brandon was talking about representing irrationals exactly,
which floats don't do. Those clever representations he talks about
will do that - for some finite set of irrationals. They still won't
represent all irrationals or all rationals - like 0.1 - exactly, so
the problems will still exist. I've done microcode implementations of
floating point representations that didn't have a hole around 0.  They
still don't work "right".

     <mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130920/3c5a094d/attachment.htm>