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 marco_ocram
Recipients marco_ocram, mark.dickinson, rhettinger, ronaldoussoren, steven.daprano, stutzbach, tim.peters, veky
Date 2020-08-26.08:43:21
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1598431401.95.0.078194188256.issue41598@roundup.psfhosted.org>
In-reply-to
Content
"- What would you expect round(2.675, ndigits=2, mode=ROUND_HALF_UP) to give? I strongly suspect that Marco would expect and want a result of 2.68. But if we follow the existing rules for round, it's going to give 2.67."
Yes, that's right. And my second humble implementation do this but only if the number have a decimal part, i mean the binary approximation is managed only for numbers with decimal positions, not for binary distortion in huge numbers with a positive exponent for example. For my application is ok but not in general, in my fast opinion a possible solution could be translate all numbers in exponential decimal format and evaluate the last digit that have to be condidered as an approximation decimal digit before applying calculations, or some kind of calculations. This is the case for example of 0.49999...9

- What would you expect round(2.712, ndigits=3, mode=ROUND_UP) to give? The binary float given by the literal 2.712 is just a touch larger than 2.712, so it should round up, giving 2.713. But again, I doubt that's what users will expect or want.  Even worse, the rounding is not idempotent: the float 2.713 is again a little larger than Decimal("2.713"), so it rounds up again: so if we round the value 2.712 twice to 3 digits using ROUND_UP, we'll get 2.714.
This is the case of 0.50000...1 for example and agreee with all stated. With the solution proposed above in my opinion could be managed this case too, translating and working on decimal representation and using last digit as rounding digit and only for this. The user will have no more the possibility to use it as a significant digit to don't have the need to guess nothing. But pheraps this means work with strings as implemented in decimals? Sorry i don't know this, but i can guess.

In the end, the problem is not simple but not impossible in my opinion, it's right that decimals are already implemented and someone could work using them if needed, i don't want to impose nothing and convince noone but it's really funny in my opinion the only built-in rounding in a cutting-edge language as Python give me the banking rounding that as an not so young :-( engineer i've learned about now and give me results the same Microsoft in documentation index as misleading. I's right as i've already stated in sums reduce the rounding error but as i've reported the more common rounding peoples have in mind is the half up rounding. These are only my considerations, the choice is your, more experienced in the field then me.
History
Date User Action Args
2020-08-26 08:43:22marco_ocramsetrecipients: + marco_ocram, tim.peters, rhettinger, ronaldoussoren, mark.dickinson, stutzbach, steven.daprano, veky
2020-08-26 08:43:21marco_ocramsetmessageid: <1598431401.95.0.078194188256.issue41598@roundup.psfhosted.org>
2020-08-26 08:43:21marco_ocramlinkissue41598 messages
2020-08-26 08:43:21marco_ocramcreate