Mark Dickinson added the comment:
Actually the negative n case *is* quite different from the positive n,
although I think it's fair to say that the issue 1869 title covers both
cases fairly well. :)
It's not at all hard to make sure that round(x, -n) correct for -22 <= -n
<= 0 and any finite
Christian Taylor added the comment:
I see what you mean. I originally thought that intermediate numbers not
being representable as floats was not the issue here, since for example
25.0/10.0 should give the exact result - despite issue 1869 clearly
mentioning the *multiplication* by powers of 10.
Mark Dickinson added the comment:
> (in this case a division by 10.0)
Of course, that's not true: division by 10.0 is harmless when the
result is exactly representable. It's actually a multiplication by
pow(10.0, -1), which is worse...
I'm currently working on incorporating David Gay's code
Mark Dickinson added the comment:
I think this *is* the same issue as 1869, at least in broad terms: the
rounding code involves inexact floating-point operations (in this case a
division by 10.0), which can result in a value that was *exactly* halfway
between two rounded values losing that e
New submission from Christian Taylor :
round(x, n) may unexpectedly round floats upwards to odd multiples of
10**(-n) if n is negative, depending on the system Python 3 is running
on. I think this is distinct from issue 1869.
Example:
>>> round(25.0, -1)
30.0
I used the following function to ch
