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

[Roman Leshchinskiy]

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