[Haskell-cafe] Mystery of an Eq instance

[damodar kulkarni]

> 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 at mired.org> wrote:

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