[Python-Dev] Return type of round, floor, and ceil in 2.6

[Tim Peters]

[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
;-)