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