marco_ocram <m.balzare...@eureka-market.com> added the comment:
"- 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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue41598>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
