[Python-Dev] Return type of round, floor, and ceil in 2.6 (original) (raw)

Tim Peters tim.peters at gmail.com
Sun Jan 6 01:20:22 CET 2008

[Tim]

Because "add a half and chop" was also in wide use for even longer, is also (Wikipedia notwithstanding) part of many standards (for example, the US IRS requires it if you do your taxes under the "round to whole dollars" option), and-- probably the real driver --is a little cheaper to implement for "normal sized" floats. Curiously, round-to-nearest can be unboundedly more expensive to implement in some obscure contexts when floats can have very large exponents (as they can in Python's "decimal" module -- this is why the proposed decimal standard allows operations like "remainder-near" to fail if applied to inputs that are "too far apart":

http://www2.hursley.ibm.com/decimal/daops.html#footnote.8 The "secret reason" is that it can be unboundedly more expensive to determine the last bit of the quotient (to see whether it's even or odd) than to determine an exact remainder).

[Guido]

Wow. Do you have an opinion as to whether we should adopt round-to-even at all (as a default)?

Yes: yes :-) There's no need to be unduly influenced by "some obscure contexts when floats can have very large exponents", and the decimal standard already weasels its way out of the bad consequences then. I should clarify that the standard "allows" relevant operations to fail then in the same sense the IRS "allows" you to pay your taxes: it's not just allowed, failure is required.

Nearest/even is without doubt the rounding method experts want most often, which is half of what makes it the best default. The other half is that, while newbies don't understand why experts would want it, the underlying reasons nevertheless act to spare newbies from subtle numeric problems.

As to what the numerically innocent /expect/, "(at least) all of the above" is my only guess. For example (and here I'm making up a very simple one to show the essence), under the Windows native Python

"%.0f" % 2.5

produces "3", while under glibc-based implementations (including Cygwin's Python) it produces "2". Over the years I've seen "bug reports" filed against both outcomes. According to the 754 standard, the glibc-based result (nearest/even rounding) is correct, and the Microsoft result is wrong. Why fight it? All the HW float operations do nearest/even rounding now too (by default), ditto the decimal module, and I'm secretly grateful the people who decided on those were downright eager to oppose Excel's numerically innocent implementors ;-)

More information about the Python-Dev mailing list