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

[Roman Leshchinskiy]

On 24/04/2010, at 22:42, Roman Leshchinskiy wrote:

> On 24/04/2010, at 22:06, Barak A. Pearlmutter wrote:
> 
>>> I was thinking of this:
>> 
>>> data T = T Double deriving ( Eq, Ord )
>> 
>>> ... GHC basically produces
>> 
>>> instance Ord T where
>>> compare (T x) (T y) = compare x y
>>> t < u = compare t u == LT
>> 
>> That is indeed what it does.  Which is a plain old bug, since it leads
>> to inconsistent behaviour between wrapped vs unwrapped values.
>> 
>> *Main> T (0/0) == T (0/0)
>> False
>> *Main> T (0/0) < T (0/0)
>> False
>> *Main> T (0/0) > T (0/0)
>> True
>> *Main> (0/0) > (0/0)
>> False
> 
> Urgh. You're right, I hadn't thought of this. Would you care to submit a bug report?

I submitted one but on further reflection, this is not so simple. Let's look at pairs as an example. At the moment, (>) is implemented basically like this:

 (a,b) > (c,d) = case compare a c of
                   LT -> False
                   EQ -> compare b d
                   GT -> True

Of course, this means that (0/0,'a') > (0/0,'a'). So we could change the implementation:

  (a,b) > (c,d) = a > c || (a == c && b > d)

But now we compare a to c twice which is very bad for, say, ([Int],Int). Clearly, we want to use the first definition but it leads to inconsistent results for Doubles. I don't see how to solve this while keeping IEEE semantics of silent NaNs.

Roman