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 agthorr, belopolsky, christian.heimes, ethan.furman, gregory.p.smith, mark.dickinson, oscarbenjamin, pitrou, ronaldoussoren, sjt, steven.daprano, stutzbach, terry.reedy, tshepang, vajrasky
Date 2013-08-20.12:43:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1377002608.43.0.244520856137.issue18606@psf.upfronthosting.co.za>
In-reply-to
Content
I agree with Oscar about sum for decimal.Decimal.  The *ideal* sum for Decimal instances would return the correctly rounded result (i.e., the exact result, rounded to the current context just once using the current rounding mode).  It seems wrong to give a guarantee of behaviour that's in conflict with this ideal.

IEEE 754 recommends a 'sum' operation (in section 9.4, amongst other reduction operations), but doesn't go so far as to either require or recommend that the result be correctly rounded.  Instead, it says "Implementations may associate in any order or evaluate in any wider format.", and then later on, "Numerical results [...] may differ among implementations due to the precision of intermediates and the order of evaluation."  It certainly *doesn't* specify that the results should be as though the context precision and rounding mode were used for every individual addition.
History
Date User Action Args
2013-08-20 12:43:28mark.dickinsonsetrecipients: + mark.dickinson, terry.reedy, gregory.p.smith, ronaldoussoren, belopolsky, pitrou, agthorr, christian.heimes, stutzbach, steven.daprano, sjt, ethan.furman, tshepang, oscarbenjamin, vajrasky
2013-08-20 12:43:28mark.dickinsonsetmessageid: <1377002608.43.0.244520856137.issue18606@psf.upfronthosting.co.za>
2013-08-20 12:43:28mark.dickinsonlinkissue18606 messages
2013-08-20 12:43:27mark.dickinsoncreate