[Python-Dev] Two proposed changes to float formatting (original) (raw)

Mark Dickinson dickinsm at gmail.com
Mon Apr 27 00:35:00 CEST 2009

On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels <Scott.Daniels at acm.org> wrote:

I had also said (without explaining:

> only the trailing zeroes with the e, so we wind up with: >      1157920892373161954235709850086879078532699846656405640e+23 >  or 115792089237316195423570985008687907853269984665640564.0e+24 >  or some such, rather than >      1.157920892373162e+77 >  or 1.15792089237316195423570985008687907853269984665640564e+77 These are all possible representations for 2 ** 256.

Understood.

but the printed decimal number I am proposing is within one ULP of the value of the binary numbery.

But there are plenty of ways to get this if this is what you want: if you want a displayed result that's within 1 ulp (or 0.5 ulps, which would be better) of the true value then repr should serve your needs. If you want more control over the number of significant digits then '%g' formatting gives that, together with a nice-looking output for small numbers.

It's only '%f' formatting that I'm proposing changing: I see a '%.2f' formatting request as a very specific, precise one: give me exactly 2 digits after the point---no more, no less, and it seems wrong and arbitrary that this request should be ignored for numbers larger than 1e50 in absolute value.

That is, for general float formatting needs, use %g, str and repr. %e and %f are for when you want fine control.

That is, the majority of the digits in int(1e308) are a fiction

Not really: the float that Python stores has a very specific value, and the '%f' formatting is showing exactly that value. (Yes, I know that some people advocate viewing a float as a range of values rather than a specific value; but I'm pretty sure that that's not the way that the creators of IEEE 754 were thinking.)

zeros get taken off the representation.  The reason I don't care is that the code from getting a floating point value is tricky, and I suspect the printing code might not easily be able to distinguish between a significant trailing zero and fictitous bits.

As of 3.1, the printing code should be fine: it's using David Gay's 'perfect rounding' code, so what's displayed should be correctly rounded to the requested precision.

Mark

More information about the Python-Dev mailing list