> 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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
