RFC: decodeFloat

[Daniel Fischer]

On Friday 26 August 2011, 22:29:20, Ian Lynagh wrote:
> On Fri, Aug 26, 2011 at 10:08:25PM +0200, Daniel Fischer wrote:
> > a nontrivial performance penalty.
> 
> It would be nice if the current function, without performance penalty,
> were ultimately renamed to unsafeDecodeFloat.

Yes, however, removing decodeFloat or changing its type would break 
existing code. I have no idea how much, so I'm not sure whether renaming 
the current function and giving decodeFloat a new type is feasible.
I suspect it's not. So then we'd have

unsafeDecodeFloat -- current
safeDecodeFloat -- new, safe
decodeFloat -- what to do with that?

And what would we do with significand/exponent on NaN/Infinity? error?

> 
> A new function could return something like
>     data DecodedFloat = Decoded Integer Int
> 
>                       | NaN
>                       | Infinity
>                       | NegativeInfinity
>                       | NegativeZero
> 
> (I'm not sure which constructors you'd want exactly).

Something like that. I'm pondering something more general, though.

data RealRep
    = I Integer
    | R Rational
    | Bin Integer Int  -- m*2^e
    | Dec Integer Int  -- m*10^e
    | NaN ?    -- not sure how to treat different NaNs
    | Infinity
    | NegativeInfinity
    | NegativeZero
    -- possibly more

to represent all (usual) types of Real numbers.

Using that as intermediate type instead of Rational in realToFrac would
allow a correct Double <-> Float (and newtypes) conversion also without 
rewrite rules (and should be faster than 'fromRational . toRational' for 
these, since it would be basically 'uncurry encodeFloat . decodeFloat').

Using that instead of Rational in reading would allow curing
http://hackage.haskell.org/trac/ghc/ticket/3897
(although that probably isn't a real life problem; and it could well be 
slower for the average input string). And we could get rid of
infinity = 1 :% 0
notANumber = 0 :% 0.

But it would be a *huge* change.