[Python-Dev] Two proposed changes to float formatting

Scott David Daniels Scott.Daniels at Acm.Org
Mon Apr 27 04:56:43 CEST 2009

ark Dickinson wrote:
 > On Sun, Apr 26, 2009 at 10:42 PM, Scott David Daniels 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.

The representation I am suggesting here is a half-way measure between
your proposal and the existing behvior.  This representation addresses
the abrupt transition that you point out (number of significant digits
drops precipitously) without particularly changing the goal of the
transition (displaying faux accuracy), without, in my (possibly naive)
view, seriously complicating either the print-generating code or the
issues for the reader of the output.

To wit, the proposal is (A) for numbers where the printed digits exceed
the accuracy presented, represent the result as an integer with an e+N,
rather than a number between 1 and 2-epsilon with an exponent that makes
you have to count digits to compare the two values, and (B) that the full
precision available in the the value be shown in the representation.

Given that everyone understands that is what I am proposing, I am OK
with the decision going where it will.  I am comforted that we are only
talking about about four wrapped lines if we go to the full integer,
which I had not realized.  Further, I agree with you that there is an
abrupt transition in represented accuracy as we cross from %f to %g,
that should be somehow addressed.  You want to address it by continuing
to show digits, and I want to limit the digits shown to a value that
reflects the known accuracy.  I also want text that compares "smoothly"
with numbers near the transition (so that greater-than and less-than
relationships are obvious without thinking, hence the representation
that avoids the "normalized" mantissa.
Having said all this, I think my compromise position should be clear.
I did not mean to argue with you, but rather intended to propose a
possible middle way that some might find appealing.

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

More information about the Python-Dev mailing list