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

Roman Leshchinskiy rl at cse.unsw.edu.au
Mon Apr 26 21:33:25 EDT 2010

```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

```