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: floating point number round failures under Linux
Type: behavior Stage:
Components: Interpreter Core Versions: Python 2.5
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: falk_steinhauer, mark.dickinson, tim.peters
Priority: normal Keywords:

Created on 2007-12-24 11:53 by falk_steinhauer, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg58983 - (view) Author: Bernhard Mayr (falk_steinhauer) Date: 2007-12-24 11:53
[Bernhard@localhost ~]$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f1=0.55
>>> f2=2.25
>>> print '%.1f, %.1f' % (f1, f2)
0.6, 2.2
f1 is rounded to the next higher value, but f2 is not.

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f1=0.55
>>> f2=2.25
>>> print '%.1f, %.1f' % (f1, f2)
0.6, 2.3

Under windows it works properly.

If the floating point numbers are encapsulated behind "round(f, 1)" 
both OS show the same output.
msg59061 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2007-12-31 19:15
Is there anything in the Python documentation that implies that '%.1f' % 2.25 should be the string '2.3'?  I know 
that the documentation for the builtin round function implies that round(2.25, 1) should be (the closest 
representable float to) 2.3, but that's a separate issue.

As far as I can tell, the float formatting of Python derives its behaviour fairly directly from that of the C 
library.  And the C language specification seems to be pretty much silent on the exact rounding behaviour of the 
%e, %f and %g conversion specifiers, so it's not clear that either the Linux result or the Windows result is wrong.  
I'm actually more surprised by the Windows result:  I'd expect %f to do round-to-nearest, with halfway results like 
this one rounded to the string with even last digit.

Incidentally, on OS X 10.4.11/Intel, I get the same as on Linux:

Python 2.5.1 (r251:54863, Dec 18 2007, 11:48:56) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print '%.1f' % 2.25
msg59062 - (view) Author: Tim Peters (tim.peters) * (Python committer) Date: 2007-12-31 21:35
Right, Unix-derived C libraries generally do IEEE-754 "round to
nearest/even" rounding, while Microsoft's do "add a half and chop"
rounding.  The Python reference manual says nothing about this, and
neither does the C standard (well, C89 doesn't; unsure about C99).

Python's round() function is independent of the platform C
string<->float conversions, and intentionally does (as documented) "add
a half and chop" rounding.
msg59064 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2007-12-31 22:30
It's worth noting that Python's round function doesn't quite work as advertised, either:

Python 2.6a0 (trunk:59634M, Dec 31 2007, 17:27:56) 
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> round(562949953421312.5, 1)
msg60128 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2008-01-19 00:55
I'm closing this as invalid.
Date User Action Args
2022-04-11 14:56:29adminsetgithub: 46035
2008-01-19 00:55:17mark.dickinsonsetstatus: open -> closed
resolution: not a bug
messages: + msg60128
2008-01-01 14:47:32christian.heimessetmessages: - msg59066
2007-12-31 22:56:53tim.peterssetmessages: + msg59066
2007-12-31 22:30:54mark.dickinsonsetmessages: + msg59064
2007-12-31 21:35:40tim.peterssetnosy: + tim.peters
messages: + msg59062
2007-12-31 19:15:17mark.dickinsonsetnosy: + mark.dickinson
messages: + msg59061
2007-12-24 11:53:14falk_steinhauercreate