Mark Dickinson added the comment:
I'm closing this as invalid.
--
resolution: - invalid
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1694
__
Changes by Christian Heimes:
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1694
__
___
Python-bugs-list mailing list
Unsubscribe:
Mark Dickinson added the comment:
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
Tim Peters added the comment:
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).
Mark Dickinson added the comment:
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.
Tim Peters added the comment:
Nice example! Yes, the round() implementation is numerically naive, in
this particular case ignoring that x+0.5 isn't necessarily representable
(it multiplies the input by 10.0, adds 0.5, takes the floor, then
divides by 10.0, and in this specific case adding 0.5
New submission from Bernhard Mayr:
[EMAIL PROTECTED] ~]$ 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
