[Haskell-cafe] RFC: decodeFloat

[Daniel Fischer]

Occasionally, the behaviour of decodeFloat and its consequences causes 
concern and/or bug reports (e.g. 
http://hackage.haskell.org/trac/ghc/ticket/3898).

The main problem is the treatment of NaNs and infinities (that it doesn't 
distinguish between 0.0 and -0.0 is a minor thing), which are converted as 
if they were ordinary finite values.

Thus, for example, decodeFloat (1/0 :: Double) = (2^52,972) and 
consequently

floor (1/0 :: Double) = 2^1024 (corresponding for round, truncate, ceiling, 
properFraction),
significand (1/0 :: Double) = 0.5,
Prelude> uncurry encodeFloat (decodeFloat (1/0 :: Float)) :: Double
3.402823669209385e38

and similar meaningless/nonsensical results for NaNs.

At its type, decodeFloat :: RealFloat a => a -> (Integer, Int), I see only 
two reasonable options,

1. leave the behaviour as it is, just warn about the exceptional cases in 
the documentation,

2. let decodeFloat raise an error when its argument is a NaN or infinite.

Both options have disadvantages, 1. makes it easy to get meaningless 
results when there's a non-finite value around, 2. incurs a nontrivial 
performance penalty.

Paying that performance penalty when dealing only with known-to-be-good 
values is undesirable, but so are meaningless results.


A third option would be providing both behaviours by adding a function.
That could take several forms,

a) leave decodeFloat as is and add safeDecodeFloat outside the RealFloat 
class, that would check the value first and then either raise an error on 
NaN/Infinity or return a Maybe (Integer, Int),

b) add a function to the RealFloat class, either leave decodeFloat as is 
and add safeDecodeFloat with the behaviour as in a) or change decodeFloat 
according to 2. and add unsafeDecodeFloat with the current behaviour.

The drawback of a) is that safeDecodeFloat would have to perform two 
checks, while with IEEE Doubles/Floats, the result could be determined by 
one check (which would also be simpler than each of isNaN and isInfinite).
Also, which module should export it?

The drawback of b) is adding a function to RealFloat, as if that wasn't big 
enough already. Since both behaviours allow a default definition in terms 
of the other, only code that by chance uses the new name would break.

What would be the community's preferred way to handle this issue?

Cheers,
Daniel