Rounding Error

[MrHamel]

Bug report

Bug description:

This made the rounds on Twitter yesterday afternoon, and was able to verify this in Linux (x86_64) on versions 3.10 and 3.12.

>>> round(2.5)
2
>>> round(3.5)
4

CPython versions tested on:

3.10, 3.12

Operating systems tested on:

Linux

[MrHamel]

I understand how the function works, but it can trip many people up because that is not proper math. Anything > 4 is rounded up, everything below it is rounded down.

[zware]

This is documented behavior:

if two multiples are equally close, rounding is done toward the even choice (so, for example, both round(0.5) and round(-0.5) are 0, and round(1.5) is 2)

See also this SO question.

[MrHamel]

Can we have the option of switching between methods, and leave the current one as the default?

Also, don't you think it is rude to close someones issue immediately after response? It's like shutting the door in ones face, which I'm sure you would not like.

[MrHamel]

Is there a reason why this was done, other than "it's the standard" ?

[zware]

Can we have the option of switching between methods, and leave the current one as the default?

If you would like to pursue that possibility, please post to the Ideas forum. If it gains significant traction there, a new feature request issue can be opened.

My personal expectation is that it is not worth complicating the round builtin.

Also, don't you think it is rude to close someones issue immediately after response? It's like shutting the door in ones face, which I'm sure you would not like.

Rudeness was not the intention, sorry about that. You are of course free to continue to post here, but this bug report will not be reopened because there is no bug to fix. This is also not the first such issue; see for example gh-91981, gh-94672, gh-89878, gh-88069, etc.

Is there a reason why this was done, other than "it's the standard" ?

Is following standards not enough? :)

When summing many rounded values, the primary school "round half up" algorithm produces a significant and noticeable bias towards larger numbers, artificially inflating the sum; "round half to even" corrects this. If "round half up" semantics are really necessary, it can be implemented relatively easily in user code, or by making use of the decimal module's multiple rounding modes.

[MrHamel]

Would it be possible to meet the community half way, by adding that decimal method to the builtin.round's documentation to know how to get the original behavior? It's just that it's a wakeup call for those that are not ready to expect such a change, compared to JavaScript, PHP, etc.

Also, the decimal.round() documentation does not have the hyperlink button to the right, like the decimal.to_integral_value() function.

[hugovk]

Opening a discussion on the ideas forum is the way forward:

https://discuss.python.org/c/ideas/6

This will involve many more from the community (who are subscribed to the forum) rather than the one or two who happen to see this in the firehose of issues :)

Thank you!

Also, the decimal.round() documentation does not have the hyperlink button to the right, like the decimal.to_integral_value() function.

Please could you share screenshots to illustrate?

[skirpichev]

Please could you share screenshots to illustrate?

@hugovk, I confirm that

round() below has no such anchor.

know how to get the original behavior?

I think that round-to-nearest mode (with ties to even) was in CPython from beginning. It's default in IEEE 754, etc.

Would it be possible to meet the community half way, by adding that decimal method to the builtin.round's documentation

I also think, that starting a d.p.o thread is a best way to go.

There is a relevant stale issue, however: #57269

[hugovk]

Thanks, it's because decimal.to_integral_value is a regular .. method:: but round is .. describe::

cpython/Doc/library/decimal.rst

Lines 894 to 903 in 7840638

	.. method:: to_integral_value(rounding=None, context=None)
	Round to the nearest integer without signaling :const:`Inexact` or
	:const:`Rounded`. If given, applies *rounding*; otherwise, uses the
	rounding method in either the supplied *context* or the current context.
	Decimal numbers can be rounded using the :func:`.round` function:
	.. describe:: round(number)
	.. describe:: round(number, ndigits)

https://www.sphinx-doc.org/en/master/usage/domains/standard.html#directive-describe

describe is new to me, but looks appropriate here because round isn't part of decimal, it's a builtin and we're referring to how round applies to decimal. meth would incorrectly say there's a decimal.round.

One option would be to put it in a new section called "Rounding decimals"?

[skirpichev]

One option would be to put it in a new section called "Rounding decimals"?

Or add round-like method round() on Decimal, with additional optional rounding argument. In sphinx docs for this method we can mention builtin round() as a restricted version of this interface.