Casey McCann
At any rate, I think we already violate the spec by not having the required "unordered" result for comparisons, and just treating every comparison involving a NaN as "GT". I don't think considering NaN as e.g. less than -Inf would violate the spec *more*.
Well, it'd be insult to injury. If memory serves me, the standard behavior is that NaN =/= NaN evaluates as true, and every other comparison evaluates as false.
Okay. I was basing my argument on the Wikipedia page, and it seems to operate with a special "unordered" value for comparisons. You could still preserve this behavior and get sensible sorting behavior, by defining an Ord instance where you explicitly specify 'compare' along with the boolean operators, and base sorting on it, rather than them. But you'd still have inconsistencies, for instance: compare NaN _ = LT NaN < _ = False and minimum xs might not be the same as head (sort xs) And so on. (Of course, the current situation is that Prelude> minimum [1,2,0/0,3] 3.0 or, probably causing this: Prelude> max (0/0) 1 NaN Prelude> max 1 (0/0) 1.0 so again, perhaps there is room for improvement here?)
But I guess it is a matter of lipstick on a pig...
How so?
In that floating point values aren't going to be a pretty sight no matter what. It currently seems to violate almost every "obvious" invariant.
What it mostly boils down to is that Haskell makes you expect things to be simple and consistent and clearly-defined and floating point values just simply aren't.
Exactly. -k -- If I haven't seen further, it is by standing in the footprints of giants