| msg86728 - (view) |
Author: Mark Dickinson (mark.dickinson) *  |
Date: 2009-04-28 11:38 |
| In all versions of Python from 2.6 up, I get the following behaviour: >>> format(123.456, '.4') '123.5' >>> format(1234.56, '.4') '1235.0' >>> format(12345.6, '.4') '1.235e+04' The first and third results are as I expect, but the second is somewhat misleading: it gives 5 significant digits when only 4 were requested, and moreover the last digit is incorrect. I propose that Python 2.7 and Python 3.1 be changed so that the output for the second line above is '1.235e+03'. Note that in both Python and C, '%.g' formatting switches to exponential notation at 1e precisely to avoid the problem of producing more significant digits than were requested; I'm proposing that the same solution be applied for '' formatting, except that since the empty format code is always required to produce at least one digit after the decimal point, the switch should happen at 1e instead of 1e. This change should not be backported to 2.6 or 3.0 since there's a small risk of breakage (particular in doctests). |
|
|
| msg86742 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-04-28 14:06 |
| I agree this should be changed. This: >>> format(1234.56, '.4') '1235.0' is definitely a problem. |
|
|
| msg86749 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2009-04-28 15:38 |
| I think the change should be deemed a bug and backported. Nothing good can come from having version differences persist or from having the odd looking output. |
|
|
| msg86797 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-29 10:41 |
| I'm working on a patch. The fix for the new-style PyOS_double_to_string using Gay's dtoa is a one-liner. The fix for the fallback code is going to take a little while longer... |
|
|
| msg86804 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-29 13:45 |
| Here's a patch for py3k; backporting to trunk should be straightforward. Backporting to 2.6 may involve more work. |
|
|
| msg86806 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-29 14:53 |
| Updated patch; the previous patch messed str() up. |
|
|
| msg86808 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-04-29 15:12 |
| I'm getting an undefined _remove_trailing_zeros using a normal build (not using the fallback code). I think it's now always called. |
|
|
| msg86811 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-29 16:08 |
| > I think it's now always called. I think you're right. I've moved remove_trailing_zeros further up, out of the #ifdef PY_NO_SHORT_FLOAT_REPR. |
|
|
| msg86816 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-04-29 16:51 |
| Using the _v2 patch, I tested both with the fallback code and with Gay's code, and both work. It's sort of shocking just how much effort you had to go through! But I can't see a simpler way to do it. It looks good to me. |
|
|
| msg86819 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-29 18:49 |
| Thanks, Eric. Applied to py3k in r72109. I've blocked it from release30- maint for now, since it will almost certainly not be possible to svnmerge it cleanly, but that doesn't preclude backporting it at some stage. I'll backport to trunk soon. |
|
|
| msg86825 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-04-29 20:47 |
| Backported to trunk in r72119. |
|
|
| msg87863 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-05-16 08:36 |
| Eric, any thoughts on whether this should be backported to 2.6 and 3.0? It looks like quite a lot of work. |
|
|
| msg87886 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-05-16 12:00 |
| I don't see any point in backporting to 3.0 at this point. While it's definitely a problem in 2.6, it seems like a big change to make in a bugfix release. I guess I'm +0 on it. |
|
|
| msg90238 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-07-07 15:19 |
| I'm not going to backport this to 2.6. The problem is that the fix for this issue is tied up with the corresponding change to str (str(1e11) produces '1e+11' in trunk and 100000000000.0 in release26-maint); I daren't change str() in 2.6, so backporting would mean separating out the str and format changes. I'm not opposed to the backport itself; it's just a lack of time and confidence of getting it right on my part. If anyone else wants to backport feel free. |
|
|
| msg90239 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-07-07 15:19 |
| ... and 3.0 is dead. |
|
|
| msg90240 - (view) |
Author: Eric V. Smith (eric.smith) * |
Date: 2009-07-07 15:28 |
| I agree that backporting it to 2.6 would be nice, but it would be a huge change. There's too much risk involved. So this will just be a new feature in 2.7. It's already in Misc/NEWS, so you're all set there. I'm closing the issue, marking it as "wont fix" because it's only assigned to 2.6 currently. |
|
|