[Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers

[Barak A. Pearlmutter]

> Please think of the poor guys trying to write high-performance code in Haskell!

Like me?  (Well, not in Haskell per-se, but in a pure functional context.)


In all seriousness, I think it is reasonable when "isNaN x" for
 x < C
 x == C
 x > C
 C < x
 C == x
 C > x
to all be False, for all floats C, even C=x, as a sort of efficient
weak Bool bottom. This is what the FP hardware does --- so it is very
efficient.

But if you force the system to choose one of the three, which is what
 compare x C
is doing, I think the result should be _|_.  Because there is no way
to choose, no reasonable Ordering to return.

It is possible to write generic "Ord n =>" code under these
conditions, if you're careful to case out <,==,> when you don't want a
NaN to kill the computation, and when necessary handle the case that
all three come out false.  That's what good numeric programmers
actually do.  But "compare" giving a wrong Ordering is an invitation
to get it wrong.

					--Barak.