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

Richard O'Keefe ok at cs.otago.ac.nz
Sun Apr 25 21:08:07 EDT 2010

```It seems to me that there's a choice here between

(A) Full conformance to the letter of IEEE arithmetic
AND full conformance to the letter of Haskell total ordering
with consequent inconvenience:
don't make floats Ord
create new IEEE comparison operations for floats

(B) Full conformance to the letter of IEEE arithmetic
and letting Haskell total ordering fend for itself
with consequent incoherence:
the present situation

(C) Full conformance to the letter of Haskell total ordering
and letting IEEE comparison rules blow away in the wind:
x == y if and only if x may be substituted for y
in any expression with no change in behaviour,
making -0.0 < 0.0 necessary I think,
and extending ordering to order NaNs

I haven't seen anyone advocate this, although it seems like an

(D) Revising the Haskell class hierarchy to have a new
ConfusingOrd class with weaker laws than Ord, and making the
floating point numbers instances of that.  This would NOT
extend Eq, so == (which identifies +0.0 and -0.0, though they
behave differently) would not be available for floats.

class ConfusingOrd a
where (===) :: a -> a -> Bool
(/==) :: a -> a -> Bool
(<)   :: a -> a -> Bool
...
class (Eq a, ConfusingOrd a) => Ord a
where x === y = x == y
x /== y = x /= y
...
compare :: a -> a -> Ord

To my feeble mind, this looks like possibly being the least
troublesome of the alternatives.  Yes, we'd stop being able
to sort collections of floats using compare, but there's a
way around that.  See (E).

(E) Have two sets of floating point numbers:
floats and ordered-floats, with explicit coercion from floats
to ordered-floats that might fail and explicit coercion from
ordered-floats to floats that always succeeds.  To sort a list,
we might do
map fromOrderedFloat (sort [x | Just x <- map toOrderedFloat ys])

>
```