[Haskell-cafe] Exception for NaN

[Ketil Malde]

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

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