Author tim.peters BreamoreBoy, aconrad, belopolsky, larry, mark.dickinson, python-dev, r.david.murray, tbarbugli, tim.peters, trcarden, vivanov, vstinner 2015-09-05.00:54:25 -1.0 Yes <1441414467.14.0.0239292021401.issue23517@psf.upfronthosting.co.za>
Content
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" ;-)
History
Date User Action Args
2015-09-05 00:54:27tim.peterssetrecipients: + tim.peters, mark.dickinson, belopolsky, vstinner, larry, r.david.murray, aconrad, BreamoreBoy, vivanov, python-dev, tbarbugli, trcarden