This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Confusions in formatfloat
Type: behavior Stage: resolved
Components: None Versions: Python 2.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: georg.brandl, lemburg, mark.dickinson, nnorwitz, tim.peters
Priority: normal Keywords:

Created on 2002-03-20 18:34 by tim.peters, last changed 2022-04-10 16:05 by admin. This issue is now closed.

Messages (8)
msg9814 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2002-03-20 18:34
stringobject.c's formatfloat seems confused in a 
couple respects.

1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling.  
What is it intending to do?  If it means what it says, 
it should be the simpler "fabs(x) >= 1e50".  But maybe 
it really intended to test "fabs(x) >= 1e25".

2. The "worst case length calc" is fantasy in some %f 
cases.  It assumes there's one digit before the 
decimal point, but, e.g., '%.100f'% 1e49 produces 
dozens of digits before the decimal point.  We're 
saved from a buffer overrun thanks to the PyOS_snprintf
() following, but unclear that truncation is sensible 
here (e.g., the user asked for a precision of 100 
here, but only gets back 50 digits after the decimal 

Complication:  we're deliberately replacing C's %f 
with C's %g in some cases, but the docs don't document 
the rules Python intends for %f.
msg9815 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-01-08 01:24
Logged In: YES 

Tim, did MALs recent checkin fix any of these problems?  Is
doc the only thing left to do?
msg9816 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2003-01-08 01:29
Logged In: YES 

Marc-Andre is in a better position to tell us what he fixed 
than I am, so assigned to him.  MAL, feel free to close this if 
you think it's history.
msg9817 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2003-01-08 19:55
Logged In: YES 

Your first finding is baffling indeed. No idea how it came
to be 
(I don't remember having added such code). The test seems to
be intended to switch from 'g' format to 'f' format at an
arbirary number of decimals before the decimal point. 
"fabs(x) >= 1e50" should do the same. Feel free to change

The second point should be fixed after my checkin:
>>> '%.100f'% 1e49
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: formatted float is too long (precision too
msg9818 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2003-01-08 21:28
Logged In: YES 

Leaving this unassgned again, with the first and last points 
unresolved (I don't have time for this now).  The "worst 
case length calc" point is probably fixed.
msg9819 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2007-03-10 07:03
The docs say, "%f conversions for numbers whose absolute value is over 1e25 are replaced by %g conversions."

So is the correct solution "if fabs(x) >= 1e25"?
msg84410 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-03-29 15:07
I've replaced the fabs(x) / 1e25 >= 1e25 test with fabs(x) >= 1e50 in 
r70678.  On IEEE 754 systems, assuming round-to-nearest, these two tests 
have identical meaning.

I've also fixed the docs, replacing 1e25 by 1e50.

Is there a good reason for

'%.100f'% 1e49

to raise OverflowError (rather than providing the requested 100 places 
after the decimal point), other than implementation convenience?
msg84414 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-03-29 16:17
The worst-case length calculations look fine to me, except that
on a system with sizeof(int) == 8 (yes, they do exist!) the
precision could end up being more than 10 digits.  I've added
a check for that in r70682.

The docs also already mention the %f -> %g conversion, so I think all
Tim's points have been addressed.
Date User Action Args
2022-04-10 16:05:07adminsetgithub: 36292
2009-03-29 16:17:49mark.dickinsonsetstatus: open -> closed
resolution: fixed
messages: + msg84414

stage: test needed -> resolved
2009-03-29 15:07:01mark.dickinsonsetmessages: + msg84410
2009-02-13 08:18:30mark.dickinsonsetassignee: nnorwitz -> mark.dickinson
2009-02-13 02:23:09ajaksu2setnosy: + mark.dickinson
stage: test needed
type: behavior
versions: + Python 2.6
2002-03-20 18:34:03tim.peterscreate