[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 ;-)). _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com