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

[Richard O'Keefe]

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
     obvious thing to think about.

(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])

>