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