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.

classification
Title: a bug in built-in function round() ?
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: Retro, eric.araujo, loewis, skip.montanaro
Priority: normal Keywords:

Created on 2010-10-14 12:55 by Retro, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (6)
msg118659 - (view) Author: Boštjan Mejak (Retro) Date: 2010-10-14 12:55
>>> round(1.255, 2)
1.25

A bug in Python interpreter?


Shold have been:

>>> round(1.255, 2)
1.26

In mathematics, the .5 part is always rounded up, so in the example the .255 should be rounded to .26 so please fix this bug.
msg118661 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2010-10-14 13:55
No, just a result of the finite machine representation of
floats:

>>> repr(1.255)
'1.2549999999999999'

so the machine representation of 1.255 is actually less
than that value and round() is doing the right thing.
msg118666 - (view) Author: Boštjan Mejak (Retro) Date: 2010-10-14 15:18
Gee, thanks for the insight. I didn't thought about the fact that binary floating point is so imprecise and can cause the round() to "error" in some situations.

In this case, the representation and the actual value are (way) off. How can that be? There are just 3 decimal numbers (.255) and Python at parsing the float is already off at the third decimal number. I'll never trust round() again. Well, actually I trust round() to do its job well -- it's the binary floating point I'm affraid of!

We must implement the decimal API to the core of Python in order to have precision.
msg118678 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-10-14 16:16
Maybe something like http://docs.python.org/library/decimal ?
msg118692 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2010-10-14 17:03
Retro> I didn't thought about the fact that binary floating point is so
    Retro> imprecise and can cause the round() to "error" in some
    Retro> situations.

Details on the limitations of floating point arithmetic are here:

    http://docs.python.org/tutorial/floatingpoint.html

Skip
msg118704 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-10-14 18:00
Please note that the error is not in the third decimal position, but only in the 16th (i.e. the difference between the intended value and the actual value is smaller than 0.0000000000000001).
History
Date User Action Args
2022-04-11 14:57:07adminsetgithub: 54310
2010-10-14 18:00:00loewissetnosy: + loewis
messages: + msg118704
2010-10-14 17:03:28skip.montanarosetmessages: + msg118692
2010-10-14 16:16:08eric.araujosetnosy: + eric.araujo
messages: + msg118678
2010-10-14 15:18:41Retrosetmessages: + msg118666
2010-10-14 14:31:03benjamin.petersonsetstatus: open -> closed
resolution: not a bug
2010-10-14 13:55:51skip.montanarosetnosy: + skip.montanaro
messages: + msg118661
2010-10-14 12:55:16Retrocreate