[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
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])
>
More information about the Haskell-Cafe
mailing list