| msg9814 - (view) |
Author: Tim Peters (tim.peters) *  |
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 point). 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) * |
Date: 2003-01-08 01:24 |
| Logged In: YES user_id=33168 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) * |
Date: 2003-01-08 01:29 |
| Logged In: YES user_id=31435 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) * |
Date: 2003-01-08 19:55 |
| Logged In: YES user_id=38388 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 this. The second point should be fixed after my checkin: >>> '%.100f'% 1e49 Traceback (most recent call last): File "", line 1, in ? OverflowError: formatted float is too long (precision too large?) |
|
|
| msg9818 - (view) |
Author: Tim Peters (tim.peters) * |
Date: 2003-01-08 21:28 |
| Logged In: YES user_id=31435 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) * |
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) * |
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) * |
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. |
|
|