[Python-Dev] Two proposed changes to float formatting

Scott David Daniels Scott.Daniels at Acm.Org
Sun Apr 26 23:42:20 CEST 2009


Mark Dickinson wrote:
 > On Sun, Apr 26, 2009 at 8:11 PM, Scott David Daniels
 > <Scott.Daniels at acm.org> wrote:
 >> As a user of Idle, I would not like to see the change you seek of
 >> having %f stay full-precision.  When a number gets too long to print
 >> on a single line, the wrap depends on the current window width, and
 >> is calculated dynamically.  One section of the display with a 8000
 >> -digit (100-line) text makes Idle slow to scroll around in.  It is
 >> too easy for numbers to go massively positive in a bug.
 >
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.

 > I see your point.  Since we're talking about floats, thought, there
 > should never be more than 316 characters in a '%f' % x: the
 > largest float is around 1.8e308, giving 308 digits before the
 > point, 6 after, a decimal point, and possibly a minus sign.
 > (Assuming that your platform uses IEEE 754 doubles.)
You are correct that I had not thought long and hard about that.
308 is livable, if not desireable.  I was remebering accidentally
displaying the result of a factorial call.
                 
 >> However, this is, I agree, a problem.  Since all of these numbers
 >> should end in a massive number of zeroes
 >
 > But they typically don't end in zeros (except the six zeros following
 > the point),
 > because they're stored in binary rather than decimal....
_but_ the printed decimal number I am proposing is within one ULP of
the value of the binary numbery.  That is, the majority of the digits
in int(1e308) are a fiction -- they could just as well be the digits of
int(1e308) + int(1e100) because 1e308 + 1e100 == 1e308
That is the sense in which I say those digits in decimal are zeroes.
My proposal was to have the integer part of the expansion be a
representation of the accuracy of the number in a visible form.
I chose the value I chose since a zero lies at the very end, and
tried to indicate I did not really care where trailing actual accuracy
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.

--Scott David Daniels
Scott.Daniels at Acm.Org



More information about the Python-Dev mailing list