On 24/04/2010, at 07:15, Barak A. Pearlmutter wrote:
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.
And yet a lot of generic code is written in terms of compare. Even deriving(Ord) only produces compare and relies on standard definitions for other methods. Don't get me wrong, I don't think the current situation is ideal (although it doesn't seem all that bad to me). But this change would have far-reaching implications for performance which ought to be evaluated before it can be seriously considered, in my opinion. Roman