[Haskell-cafe] Exception for NaN
ketil at malde.org
Wed May 18 09:55:41 CEST 2011
Casey McCann <syntaxglitch at gmail.com> writes:
>> 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
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]
or, probably causing this:
Prelude> max (0/0) 1
Prelude> max 1 (0/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"
> 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.
If I haven't seen further, it is by standing in the footprints of giants
More information about the Haskell-Cafe