classification
Title: format(1234.5, '.4') gives misleading result
Type: behavior Stage: resolved
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: eric.smith, mark.dickinson, rhettinger
Priority: normal Keywords: patch

Created on 2009-04-28 11:38 by mark.dickinson, last changed 2009-07-07 15:28 by eric.smith. This issue is now closed.

Files
File name Uploaded Description Edit
issue5864.patch mark.dickinson, 2009-04-29 14:53
issue5864_v2.patch mark.dickinson, 2009-04-29 16:08
Messages (16)
msg86728 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) 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, '%.<precision>g' formatting switches to
exponential notation at 1e<precision> 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<precision-1>
instead of 1e<precision>.

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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2009-04-29 14:53
Updated patch; the previous patch messed str() up.
msg86808 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2009-04-29 20:47
Backported to trunk in r72119.
msg87863 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2009-07-07 15:19
... and 3.0 is dead.
msg90240 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) 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.
History
Date User Action Args
2009-07-07 15:28:41eric.smithsetstatus: open -> closed
messages: + msg90240

assignee: mark.dickinson
resolution: wont fix
stage: patch review -> resolved
2009-07-07 15:19:47mark.dickinsonsetmessages: + msg90239
versions: - Python 3.0
2009-07-07 15:19:14mark.dickinsonsetassignee: mark.dickinson -> (no value)
messages: + msg90238
2009-05-16 12:00:01eric.smithsetmessages: + msg87886
2009-05-16 08:37:30mark.dickinsonsetpriority: normal
versions: + Python 2.6, Python 3.0, - Python 3.1, Python 2.7
2009-05-16 08:36:23mark.dickinsonsetmessages: + msg87863
2009-04-29 20:47:53mark.dickinsonsetmessages: + msg86825
2009-04-29 18:49:52mark.dickinsonsetmessages: + msg86819
2009-04-29 16:51:07eric.smithsetmessages: + msg86816
stage: needs patch -> patch review
2009-04-29 16:08:59mark.dickinsonsetfiles: + issue5864_v2.patch

messages: + msg86811
2009-04-29 15:12:30eric.smithsetmessages: + msg86808
stage: patch review -> needs patch
2009-04-29 14:54:13mark.dickinsonsetstage: needs patch -> patch review
2009-04-29 14:54:04mark.dickinsonsetfiles: - issue5864.patch
2009-04-29 14:53:56mark.dickinsonsetfiles: + issue5864.patch

messages: + msg86806
2009-04-29 13:45:48mark.dickinsonsetfiles: + issue5864.patch
keywords: + patch
messages: + msg86804
2009-04-29 10:41:53mark.dickinsonsetassignee: mark.dickinson
messages: + msg86797
2009-04-28 15:38:50rhettingersetnosy: + rhettinger
messages: + msg86749
2009-04-28 14:06:57eric.smithsetmessages: + msg86742
2009-04-28 11:38:20mark.dickinsoncreate