Message250797
| Author |
tim.peters |
| Recipients |
mark.dickinson, pitrou, tim.peters |
| Date |
2015年09月15日.19:24:37 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1442345077.64.0.0433158743993.issue25129@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Stare at footnote 2 for the Reference Manual's "Binary arithmetic operations" section:
"""
[2] If x is very close to an exact integer multiple of y, it’s possible for x//y to be one larger than (x-x%y)//y due to rounding. In such cases, Python returns the latter result, in order to preserve that divmod(x,y)[0] * y + x % y be very close to x.
"""
This is such a case.
>>> x
4.679999999999999e-06
>>> y
6e-08
>>> divmod(x,y)[0] * y + x % y == x
True
>>> (x/y) * y + x % y == x
False
>>> ((x/y) * y + x % y) / x # and not close at all
1.0128205128205128
Yes, trying to preserve identities in floating-point always was a fool's errand ;-)
Note that "but x is an _exact_ integer multiple of y, not just 'very close to'" would be succumbing to an illusion:
>>> dx = decimal.Decimal(x)
>>> dy = decimal.Decimal(y)
>>> dx / dy
Decimal('77.99999999999999426488108630')
It's just that x/y _appears_ to be an exact integer (78) due to rounding. As the decimal calcs show, infinite-precision floor division really would return 77. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2015年09月15日 19:24:37 | tim.peters | set | recipients:
+ tim.peters, mark.dickinson, pitrou |
| 2015年09月15日 19:24:37 | tim.peters | set | messageid: <1442345077.64.0.0433158743993.issue25129@psf.upfronthosting.co.za> |
| 2015年09月15日 19:24:37 | tim.peters | link | issue25129 messages |
| 2015年09月15日 19:24:37 | tim.peters | create |
|