RFC: decodeFloat
Daniel Fischer
daniel.is.fischer at googlemail.com
Sat Aug 27 01:24:10 CEST 2011
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.
More information about the Libraries
mailing list