Message249875
Goodness. It's the properties of "randomly chosen decimals" that have nothing to do with timestamps ;-) timestamps aren't random, so "statistical bias" is roughly meaningless in this context. I gave a specific example before of how nearest/even destroys obvious regularities in a _sequence_ of timestamps, where half-up preserves as much of the input regularity as possible. That's worth more than a million abstract "head arguments" on Wikipedia.
But it doesn't make a lick of real difference either way. We're rounding to microseconds, and there are only 64 "fractional parts" where the methods could _possibly_ deliver different results: those of the form i/128 for i in range(1, 128, 2). All and only those are exactly representable in base 2, and require exactly 7 decimal digits "after the decimal point" to express in decimal, _and_ end with "5" in decimal. Half end with "25" while the other half with "75". So Alex's 1/128 is one of the only 32 possible fractional parts where it makes a difference. We systematically force all these cases to even, and dare think that's _not_ "biased"? Half-up would leave half the results even and half odd, exactly the same as the _input_ odd/even distribution of the 6th digit. And preserve the input strict alternation between even and odd in the 6th digit. nearest/even destroys all of that.
Except that, I agree, there's no arguing with "Dutch rounding" ;-) |
|
Date |
User |
Action |
Args |
2015-09-05 00:54:27 | tim.peters | set | recipients:
+ tim.peters, mark.dickinson, belopolsky, vstinner, larry, r.david.murray, aconrad, BreamoreBoy, vivanov, python-dev, tbarbugli, trcarden |
2015-09-05 00:54:27 | tim.peters | set | messageid: <1441414467.14.0.0239292021401.issue23517@psf.upfronthosting.co.za> |
2015-09-05 00:54:27 | tim.peters | link | issue23517 messages |
2015-09-05 00:54:25 | tim.peters | create | |
|