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

Tim Peters tim.peters at gmail.com
Sun Jan 6 06:12:51 CET 2008

[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 - ny (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 - 136n = 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 ;-)).

More information about the Python-Dev mailing list