Why Python's integer division floors (2010)
python-history.blogspot.com
Why Python's integer division floors (2010)
1–10 of 102 posts
Re: Why Python's integer division floors (2010)
#2Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with modulo doesn't need to hold for negative numbers.
Re: Why Python's integer division floors (2010)
#3Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with modulo doesn't need to hold for negative numbers.
Quantify "well known". Historically enough variation existed in this area [1], and C only happened to copy FORTRAN's behavior for the sake of compatibility.
[1] https://en.wikipedia.org/wiki/Modulo#In_programming_language...
Re: Why Python's integer division floors (2010)
#4Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with modulo doesn't need to hold for negative numbers.
I strongly disagree. I would estimate that in 90% of cases where I use modulo in languages that truncate (instead of flooring), I write (a % b + b) % b, or something similar, just to get the right behaviour. The exceptional cases are those where I can convince myself that negative numbers simply won't come up. (It's never because I actually want the other behaviour for negative numbers.)
- When using modulo to access an array cyclically. (You might get lucky that your language allows using negative numbers to index from the back. In that case, both conventions work.) - When lowering the resolution of integers. If you round to zero, you get strange artifacts around zero, because -b+1, ..., -1, 0, 1, ..., b-1 all go to zero when dividing by b. That's 2b-1 numbers. For every other integer k, there are only b numbers (namely bk, bk+1, ..., bk+b-1).
I have never seen a case where truncation was the right thing to do. (When dealing with integers. Floats are different, of course, but they are not what this is about.)
Re: Why Python's integer division floors (2010)
#5Note the top comment by “ark” - there’s really no perfect solution here.
In the floating-point case, you have to choose between negative remainders or potentially inexact results. And you definitely want integer division to work the same as float division.
Re: Why Python's integer division floors (2010)
#6Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with modulo doesn't need to hold for negative numbers.
> Changing well known behavior for something no one is really going to need.
On the contrary I can't imagine when and why anybody would want truncation. That's just a side effect of the used algorithm and not something that actually makes much (any?) sense.
Re: Why Python's integer division floors (2010)
#7Changing well known behavior for something no one is really going to need. The justification makes sense, but it breaks convention and the relationship with modulo doesn't need to hold for negative numbers.
Quantify "well known". Historically enough variation existed in this area [1], and C only happened to copy FORTRAN's behavior for the sake of compatibility. [1] https://en.wikipedia.org/wiki/Modulo#In_programming_language...
Python does follow the convention, but what I am wondering now is why did FORTRAN break it ?
Re: Why Python's integer division floors (2010)
#8How many integer 2s go in to 7?
3 not 4..
Not a hard question to answer.
Re: Why Python's integer division floors (2010)
#9Earlier quoted context omitted.
Quantify "well known". Historically enough variation existed in this area [1], and C only happened to copy FORTRAN's behavior for the sake of compatibility. [1] https://en.wikipedia.org/wiki/Modulo#In_programming_language...
Python does follow the convention, but what I am wondering now is why did FORTRAN break it ?
Fortran is old – 1958 onwards. It has precedence here, though at what point it separated the two behaviours into mod and modulo functions I don’t know.
Edit: From what I can tell, standardised in Fortran 90, presumably older than that.
Re: Why Python's integer division floors (2010)
#10Earlier quoted context omitted.
Quantify "well known". Historically enough variation existed in this area [1], and C only happened to copy FORTRAN's behavior for the sake of compatibility. [1] https://en.wikipedia.org/wiki/Modulo#In_programming_language...
Python does follow the convention, but what I am wondering now is why did FORTRAN break it ?
Maybe because FORTRAN arrays index from 1 by default?