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

[Barak A. Pearlmutter]

> The problem are not so much the additional instructions. Rather,
> it's the fact that compare for Float and Double can fail at all
> which inhibits some optimisations. For instance, GHC is free to
> eliminate the comparison in (x `compare` y) `seq` a but wouldn't be
> with your change. It doesn't actually do that at the moment, which
> looks like an optimiser deficiency to me. But in any case, the
> property "can fail" has a significant effect on optimisations
> sometimes.

Yeah, the IEEE FP people knew what they were doing from a performance
perspective.  This kind of problem (eg, being able to remove a dead
x+y without proving all kinds of conditions on x and y) is exactly
whey they mandated a NaN value upon arithmetic exception rather than
making the computation fail with a synchronous exception.  Or at
least, a mode, almost always used by default, with this behaviour.

What you're describing is a similar performance problem, which argues
for a similar solution:

  data Ordering = LT, EQ, GT, OoO

where OoO means Out of Order.

But just because you could doesn't mean you'd have to do this:

  compare x y =
    case map (\o->x`o`y) [(<),(<=),(==),(>=),(>),(/=)] of
      [True,True,False,False,False,True] -> LT
      [False,True,True,True,False,False] -> EQ
      [False,False,False,True,True,True] -> GT
      otherwise                          -> OoO

					--Barak.