PEP 238 - The // operator should truncate instead of floor
Hi all First, some background. I've recently tried to port a certain library that manipulates dates from C. Some of the core functions contain heavy integer math (very long formulae), and after implementing them I tested them to see the give the desired results. I got very odd results, which surprised me since I copied the formula letter to letter. I decided to investigate further, and after trying to evaluate several expressions in the python console, I realized it was the integer division's fault. For some reason, the integer division behaves unexpectedly for negative integers. Looking deeper in the python PEPs, I saw that division on integers is defined as: idiv(a, b) = floor(fdiv(a, b)). This non-quotient division leads to some odd results, e.g. Python seems to think -3/2+3/2 = -1. This is clearly, and correct me if I'm mistaken - wrong. Now, seeing as Python 3000 is getting closer, and backwards compatibility isn't an issue, I believe it would be a good idea to change the // operator (which will be used for integer division) to behave as quotient, i.e.: a // b = trunc(a / b) Dany
2007/8/29, dany <danzat@gmail.com>:
FAQ: Why does -22 / 10 return -3? http://www.python.org/doc/faq/programming/#why-does-22-10-return-3 Past discussion: <http://mail.python.org/pipermail/python-list/2005-February/thread.html#30657...> Also, FYI, TCL and Ruby behave the same way. -- Lino Mastrodomenico E-mail: l.mastrodomenico@gmail.com
On 8/29/07, dany <danzat@gmail.com> wrote:
Rounding integer division can't be defined such that fractional information is preserved. For example, the sum 1/2 + 1/2 (with rounding division), doesn't equal 1 whether the rounding is done up or down. Python's choice to round to the floor of the exact quotient is entirely in order, and in fact, I've found it very useful in some of my code. There is an easy fix for your problem: write a custom division function, e.g. def div(a, b): if a*b > 0: return a // b else: return -(abs(a)//abs(b)) Either that, or use any of the modules for rational arithmetic available for Python. Fredrik
Lino already pointed you to the relevant FAQ entry, but since you explicitly asked for it: you are mistaken, the result is right. It would have been good if you had indicated what result you had expected instead. I assume 0; to get 0, you have to write -(3/2)+3/2, or 0-3/2+3/2. Regards, Martin
2007/8/29, dany <danzat@gmail.com>:
FAQ: Why does -22 / 10 return -3? http://www.python.org/doc/faq/programming/#why-does-22-10-return-3 Past discussion: <http://mail.python.org/pipermail/python-list/2005-February/thread.html#30657...> Also, FYI, TCL and Ruby behave the same way. -- Lino Mastrodomenico E-mail: l.mastrodomenico@gmail.com
On 8/29/07, dany <danzat@gmail.com> wrote:
Rounding integer division can't be defined such that fractional information is preserved. For example, the sum 1/2 + 1/2 (with rounding division), doesn't equal 1 whether the rounding is done up or down. Python's choice to round to the floor of the exact quotient is entirely in order, and in fact, I've found it very useful in some of my code. There is an easy fix for your problem: write a custom division function, e.g. def div(a, b): if a*b > 0: return a // b else: return -(abs(a)//abs(b)) Either that, or use any of the modules for rational arithmetic available for Python. Fredrik
Lino already pointed you to the relevant FAQ entry, but since you explicitly asked for it: you are mistaken, the result is right. It would have been good if you had indicated what result you had expected instead. I assume 0; to get 0, you have to write -(3/2)+3/2, or 0-3/2+3/2. Regards, Martin
participants (4)
-
"Martin v. Löwis" -
dany -
Fredrik Johansson -
Lino Mastrodomenico