This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients BreamoreBoy, aconrad, belopolsky, larry, mark.dickinson, python-dev, r.david.murray, tbarbugli, tim.peters, trcarden, vivanov, vstinner
Date 2015-09-05.02:28:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1441420091.03.0.443946185089.issue23517@psf.upfronthosting.co.za>
In-reply-to
Content
Bah.  It doesn't matter who's consuming the rounding of a binary float to decimal microseconds:  there are only 32 possible fractional parts where nearest/even and half-up deliver different results.  half-up preserves properties of these specific inputs that nearest/even destroys.  These inputs themselves have no bias - they're utterly uniformly spaced.

Not only does nearest/even _introduce_ bias on these inputs by destroying these properties, it doesn't even preserve the spacing between them.  Half-up leaves them all 5 microseconds apart, while nearest/even creates a bizarre "sometimes 4 microseconds apart, sometimes 6" output spacing out of thin air.

So it's not a question of "when in doubt" to me, it's a question of "live up to what the docs already say".  Although, again, it doesn't make a lick of real difference.  That's why we'll never stop arguing about it ;-)
History
Date User Action Args
2015-09-05 02:28:11tim.peterssetrecipients: + tim.peters, mark.dickinson, belopolsky, vstinner, larry, r.david.murray, aconrad, BreamoreBoy, vivanov, python-dev, tbarbugli, trcarden
2015-09-05 02:28:11tim.peterssetmessageid: <1441420091.03.0.443946185089.issue23517@psf.upfronthosting.co.za>
2015-09-05 02:28:11tim.peterslinkissue23517 messages
2015-09-05 02:28:10tim.peterscreate