[Python-Dev] Expert floats

[Andrew Koenig]

> It is, but it wasn't practical.  754 requires that float->string done to
> 17 significant digits, then back to float again, will reproduce the
> original float exactly.

But that rules out those hypothetical machines with greater precision on
which you are basing your argument.

> It doesn't require perfect rounding (there are different
> accuracy requirements over different parts of the domain -- it's
> complicated), and it doesn't require that a conforming float->string
> operation be able to produce more than 17 meaningful digits.

I thought that 754 requires input and output to be no more than 0.47 LSB
away from exact.  Surely the spirit of 754 would require more than 17
significant digits on machines with more than 56-bit fractions.

> So long as Python relies on the platform C, it can't assume more than that
> is available.  Well, it can't even assume that much, relying on C89, but
> almost all Python fp behavior is inherited from C, and as a "quality of
> implementation" issue I believed vendors would, over time, at least try to
> pay lip service to 754.  That prediction was a good one, actually.

Understood.  What I meant when I started this thread was that I think things
would be better in some ways if Python did not rely on the underlying C
library for its floating-point conversions--especially in light of the fact
that not all C libraries meet the 754 requirements for conversions.

> > Here's another way to look at it.  Suppose I want to convert 2**-30 to
> > decimal.  On a 64-bit machine, I can represent that value to 17
> > significant digits as 9.31322574615478516e-10.  However, I can also
> > represent it exactly as 9.3132257461547851625e-10.

> On Windows (among others), not unless you write your own float->string
> routines to get those "extra" digits.

No -- the representation is exact regardless of whether a particular
implementation is capable of producing it :-)

> BTW, it's actually easy to write perfect-rounding float<->string routines
> in Python.  The drawback is (lack of) speed.

Agreed.  I did it in C many moons ago.

> > If you are arguing that I can get a better approximation on a machine
> > with more precision if I write the first of these representations,
> > doesn't that argument suggest that the second of these representations
> > is better still?


> Yes.  The difference is that no standard requires that C be able to
> produce the latter, and you only suggest David Gay's code because you
> haven't tried to maintain it <wink -- but it is a cross-platform mess>.

Naah - I also suggested it because I like the Scheme style of conversions,
and because I happen to know David Gay personally.  I have no opinion about
how easy his code is to maintain.

I completely agree that if you're going to rely on the underlying C
implementation for floating-point conversions, there's little point in
trying to do anything really good--C implementations are just too variable.