Repository navigation
Issue with Round Function in Python #123811
Description
Activity
Hmm, is this causing any actual problems in practice?
0.0and-0.0are, more or less, equivalent numbers.Reacted by Tim Peters- Reacted by Peter Bierma, W. H. Wang, filipwojtowicz, Kirill Podoprigora, Tim Peters, Raymond Hettinger and Shantanu
@mdickinson, @tim-one, what are your thoughts? Should we explicitly document that
round()can return a negative zero?I think that we should add tests for this in any case, to prevent code degradation.
Reacted by Tim Peters and ShantanuIt shouldn't be changed. It's a form of "underflow to 0", and all relevant standards require that the sign bit be retained in such cases. Python's
round()isn't mentioned in the standards, so this is a "to be consistent with the obvious intent of ..." thing.Mixed feelings about documenting it. Hardly anyone will care, and filtering out irrelevant (to them) "doc bloat" is an ongoing burden for all other readers. If it has to be documented, I'd recommend a footnote.
But, yes, it absolutely should be tested.
Reacted by Konstantin Masich, Alex Waygood, Sergey B Kirpichev, Alperen, Kavinkumar, Mark Dickinson, Shantanu and Mats LindhIn some sense, it's tested, e.g. here:
cpython/Lib/test/test_float.py
Line 896 in 11fa119
This test just ignores difference between 0.0 and -0.0. Probably, that line could be just changed to use assertFloatsAreIdentical() (see also #121071). Or did I miss something and we need more test cases?Edit: pr is ready, #123829
Reacted by Tim Peters- added a commit that references this issue
on Sep 8, 2024 This isn't worth much effort.
assertFloatsAreIdentical()certainly - equality testing is useless (+0.0 == -0.0). In addition to checking thatround(-123.456, n)returns -0.0, also check that +0.0 is returned if the first argument is negated. Good enough, I think.also check that +0.0 is returned if the first argument is negated
Yeah, that one was right above. I just did replace for all tests with ±0.0 on rhs.
But I dislike adding assertFloatsAreIdentical() helper yet in another place. So, I would appreciate if something like #121071 will be merged first.
Reacted by Bénédikt Tran@skirpichev: Can we close this issue or do you plan further changes?
@vstinner, on my taste - documentation shouldn't be changed. This looks as a very special corner case with natural behaviour for whose who do care about distinction between
0.0and-0.0. Most users, probably, won't notice this because zeros are equal.As Serhiy asked Mark too - lets wait his opinion. Tim Peters seems to be -0 on this.
Reacted by Tim Peters7 remaining items
Fist try to make
__round__()converting a negative zero to positive zero and check whether anything fails.New pr: #124007
- added a commit that references this issue
on Sep 13, 2024 Two backport pr aren't merged.
Now merged.
Reacted by Peter Bierma
Bug report
Bug description:
Description of the Issue:
The
roundfunction does not seem to handle certain floating-point numbers correctly. For example, when rounding the number -1357.1357 to negative 4 decimal places, the function returns -0.0 instead of the expected 0.0.Steps to Reproduce:
Expected Result: The output should be 0.0.
Actual Result: The output is -0.0.
Environment Details Tested:
--Python Version: 3.12.5, Operating System: Windows 11.
--Python Version: 3.12.3, Operating System: Ubuntu.
Additional Information: I have verified this issue on multiple machines and with different Python versions. The issue persists across all tested environments.
CPython versions tested on:
3.12, 3.13
Operating systems tested on:
Linux, Windows
Linked PRs