On Fri, Sep 20, 2013 at 7:35 PM, damodar kulkarni <kdamodar2...@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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe