On 24/04/2010, at 19:56, Barak A. Pearlmutter wrote: >> And yet a lot of generic code is written in terms of compare. > > That's can be an advantage, because often that code *should* blow up > when it gets a NaN. E.g., sorting a list of Floats which includes a > NaN.
However, often you will know that the list doesn't contain NaNs and will still have to pay a performance penalty. It's a question of what the right default is - safety or performance. In the case of floating point numbers, I'm leaning towards performance. That said, I would be very much in favour of providing a SafeFloat or whatever type with much safer semantics than IEEE floats and trying to get people to use that type by default unless they really need the performance. >> Even deriving(Ord) only produces compare and relies on standard >> definitions for other methods. > > I don't think that's actually a problem. Surely the IEEE Floating > Point types would give their own definitions of not just compare but > also <, <=, etc, overriding the problematic deriving(Ord) definitions > of comparison in terms of compare and vice-versa. I was thinking of this: data T = T Double deriving ( Eq, Ord ) Unless I'm mistaken, at the moment GHC basically produces instance Ord T where compare (T x) (T y) = compare x y t < u = compare t u == LT ... That is, all comparisons on T would be paying the "NaN performance tax". Roman _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe