Mark Dickinson <[email protected]> added the comment:
@AVicennA: as the docs you linked to explain, this is not a bug: `round` is
giving the correct result in all cases (or at least, as correct as is possible
given the use of binary floating-point).
Let's take just the first case, `round(2.675, 2)`. `2.675` is a numeric literal
in the source that's converted to a Python object of type `float` whose value
is stored[*] using the IEEE 754 binary64 format. The exact value of that object
is then 2.67499999999999982236431605997495353221893310546875.
So the value that Python sees when rounding is *less* than the halfway case
2.675, so it rounds down to 2.67. If you think that's not the right thing to
do, I have a question for you: what result would you expect
`round(2.6749999999999998, 2)` to give?
Your proposed my_round replacement is not a fix: unlike *round*, it does *not*
do correct rounding in all cases, and does not always give the naively expected
result in all cases either. To give just one example of many:
>>> my_round(4.395, 2)
4.39
So I don't really understand what action you're proposing here. `round` is as
good as it can reasonably be, and the documentation already explains the
weaknesses and links to further reading. Unless you're proposing that Python
adopt decimal floating-point for its core float type, or that two-argument
round be deprecated, there not really anything to be done here.
[*] Disclaimer: use of IEEE 754 is not guaranteed, but is overwhelmingly likely
on common platforms.
----------
nosy: +mark.dickinson
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue39059>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
