Message108601
| Author |
belopolsky |
| Recipients |
belopolsky, mark.dickinson, mcherm, rhettinger, stutzbach, tim.peters, vstinner |
| Date |
2010年06月25日.14:41:26 |
| SpamBayes Score |
0.020008953 |
| Marked as misclassified |
No |
| Message-id |
<1277476888.53.0.239622209471.issue8860@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
>> The timedelta(seconds=0.6112295) example is handled correctly
> No, it's not! It's being rounded *up* where it should be
> being rounded *down*.
Let me try to reformulate the issue. When use is entering 0.6112295, she means 0.6112295, not 0x1.38f312b1b36bdp-1 or 0.61122949999999998116351207499974407255649566650390625 which are exact values of the underlying binary representation of 0.6112295. Modern Python is able to round 0.6112295 to 6 decimal places correctly:
>>> round(0.6112295, 6)
0.611229
and timedelta should do the same, but it does not:
>>> timedelta(seconds=0.6112295)
datetime.timedelta(0, 0, 611230)
With respect to accumulation, I believe the invariant that we want to have should be
timedelta(x=a, y=b, ...) == timedelta(x=a) + timedelta(y=b)
while the alternative (using higher precision addition with rounding at the end) may be more accurate in some cases, the above looks least surprising. |
|