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

[Tim Peters]

[Tim]
>> 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":

[Daniel Stutzbach]
> Just to be clear, this problem doesn't come up in round(), right?

Right!  It's unique to 2-argument mod-like functions.


> Because in round(), you just test the evenness of the last digit
> computed.  There is never a need to compute extra digits just to
> perform the test.

Right, round has to compute the last (retained) digit in any case.

For mod(x, y) (for various definitions of mod), the result is x - n*y
(for various ways of defining an integer n), and there exist efficient
ways to determine the final result without learning anything about the
value of n in the process.  For example, consider Python's pow(10,
100000000, 136).  It goes very fast to compute the answer 120, but
internally Python never develops any idea about the value of n such
that 10**100000000 - 136*n = 120.  Is n even or odd?  "remainder-near"
can care, but there's no efficient way I know of to find out (dividing
a 100-million digit integer by 136 to find out isn't efficient ;-)).