◐ Shell
clean mode source ↗

Message 249875 - Python tracker

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" ;-)