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.

Yes, and then all the torrent of explanation I got here about the intricacies of floating point operations would seem more appropriate. Then you can tell such a person "how is the demand for general notion of equality for floats tantamount to a demand for an oxymoron? because depending on various factors the notion of equality for float itself floats (sorry for the pun)."

But in the given situation, such an explanation seems uncalled for as it goes like: "we have given you the Eq instance on the floating point types BUT still you are expected NOT to use it because the floating point thingy is very blah blah blah..." etc.

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.

not much of a problem with that as then it would be more like people who do unsafePerformIO, where Haskell clearly tells you that you are on your own. You might provide them `unsafePerformEqOnFloats` for instance. And then if someone complains that the `unsafePerformEqOnFloats` doesn't test for equality as in equality, by all means flood them with "you asked for it, you got it" type messages and the above mentioned explanations about the intricacies of floating point operations.

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.

This seems better. Let people have the support for floating point types in some other libraries IF at all they want to have them but then it would bear no burden on the Num typeclass and more importantly on the users of the Num class.

In this case, such people might implement their __own__ notion of equality for floating points. And if they intend to do such a thing, then it would not be much of an issue to expect from them the detailed knowledge of all the intricacies of handling equality for floating points... as anyway they themselves are asking for it and they are NOT relying on the Haskell's Num typeclass for it.



Thanks and regards,
-Damodar Kulkarni


On Sat, Sep 21, 2013 at 9:46 AM, Mike Meyer <mwm@mired.org> wrote:
On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni <kdamodar2000@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