<div dir="ltr"><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Making floats not be an instance of Eq will<div>just cause those people to ask "Why can't I compare floats for</div>
equality?". This will lead to pretty much the same explanation.</blockquote><div><br></div><div>
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)."<br>
<br>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.<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">It
<div>will also mean that people who know what they're doing who want to do</div><div>so will have to write their own code to do it.</div></blockquote><div><br>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.<br>
<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>Given that we have both Data.Ratio and Data.Decimal, I would argue</div><div>that removing floating point types would be better than making them</div>
<div>not be an instance of Eq.</div></blockquote><div><br>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.<br>
</div><div><br></div></div></div>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.<br><br><br><div class="gmail_extra"><br clear="all"><div>Thanks and regards,<br>-Damodar Kulkarni<br></div>
<br><br><div class="gmail_quote">On Sat, Sep 21, 2013 at 9:46 AM, Mike Meyer <span dir="ltr"><<a href="mailto:mwm@mired.org" target="_blank">mwm@mired.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div><div>On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni <<a href="mailto:kdamodar2000@gmail.com" target="_blank">kdamodar2000@gmail.com</a>> wrote:</div><div>> This seems a good step forward, removing the Eq instance altogether on</div>
<div>> floating point types would be much better; (unless as pointed out by</div><div>> Brandon, "you have a very clever representation that can store</div><div>> (floats) in terms of some operation like sin(x) or ln(x) (with</div>
<div>> infinite precision)")</div><div><br></div></div><div>Please don't. The problem isn't with the Eq instance. It does exactly</div><div>what it should - it tells you whether or not two floating point</div>
<div>
objects are equal.</div><div><br></div><div>The problem is with floating point arithmetic in general. It doesn't</div><div>obey the laws of arithmetic as we learned them, so they don't behave</div><div>the way we expect. The single biggest gotcha is that two calculations</div>
<div>we expect to be equal often aren't. As a result of this, we warn</div><div>people not to do equality comparison on floats.</div><div><br></div><div>So people who don't understand that wind up asking "Why doesn't this</div>
<div>behave the way I expect?" Making floats not be an instance of Eq will</div><div>just cause those people to ask "Why can't I compare floats for</div><div>equality?". This will lead to pretty much the same explanation. It</div>
<div>will also mean that people who know what they're doing who want to do</div><div>so will have to write their own code to do it.</div><div><br></div><div>It also won't solve the *other* problems you run into with floating</div>
<div>point numbers, like unexpected zero values from the hole around zero.</div><div><br></div><div>Given that we have both Data.Ratio and Data.Decimal, I would argue</div><div>that removing floating point types would be better than making them</div>
<div>not be an instance of Eq.</div><div><br></div><div>It might be interesting to try and create a floating-point Numeric</div><div>type that included error information. But I'm not sure there's a good</div><div>
value for the expression 1.0±0.1 < 0.9±0.1.</div><div><br></div><div>Note that Brandon was talking about representing irrationals exactly,</div><div>which floats don't do. Those clever representations he talks about</div>
<div>will do that - for some finite set of irrationals. They still won't</div><div>represent all irrationals or all rationals - like 0.1 - exactly, so</div><div>the problems will still exist. I've done microcode implementations of</div>
<div>floating point representations that didn't have a hole around 0. They</div><div>still don't work "right".</div><span><font color="#888888"><div><br></div><div> <mike</div><div>
<br></div></font></span></div>
</blockquote></div><br></div></div>