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 mark.dickinson
Recipients jeroen1225, mark.dickinson, skrah
Date 2014-07-07.12:00:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1404734427.52.0.610917669043.issue21929@psf.upfronthosting.co.za>
In-reply-to
Content
This is working as designed, though admittedly the cause of the unexpected results is non-obvious.

In Python 2, there's no way to implement `round` for a general type:  instead, the `round` function converts its *input* to a Python (binary) float, and then rounds the resulting value.  So you're effectively doing:

>>> from decimal import Decimal
>>> round(float(Decimal('167.75')), 1)
167.8
>>> round(float(Decimal('167.85')), 1)
167.8
>>> round(float(Decimal('167.95')), 1)
167.9

And the results above are explainable in terms of rounding the corresponding floating-point value:  the closest exactly representable binary float to 167.85 is 167.849999999999994315658113919198513031005859375, which is a touch less than the halfway mark, so rounds down.  Similarly, the closest exactly representable float to 167.95 is 167.94999999999998863131622783839702606201171875, which again rounds down.  167.75 is already exactly representable as a float, so there you get the expected result.

In Python 3, `round` rounds the Decimal object directly without converting to float first, so you shouldn't see the above problems.  In Python 2, you'll need to stick to your quantize approach.
History
Date User Action Args
2014-07-07 12:00:27mark.dickinsonsetrecipients: + mark.dickinson, skrah, jeroen1225
2014-07-07 12:00:27mark.dickinsonsetmessageid: <1404734427.52.0.610917669043.issue21929@psf.upfronthosting.co.za>
2014-07-07 12:00:27mark.dickinsonlinkissue21929 messages
2014-07-07 12:00:26mark.dickinsoncreate