Yes that makes perfect sense. So why is int(-1.5) == -1? It should be -2.
Why Python's integer division floors (2010)
11–20 of 102 posts
Re: Why Python's integer division floors (2010)
#12Yes that makes perfect sense. So why is int(-1.5) == -1? It should be -2.
The same reason int(-1.999) is -1; The operation is different to integer division. I think of it as taking the "integer" part of the float.
Re: Why Python's integer division floors (2010)
#13Yes that makes perfect sense. So why is int(-1.5) == -1? It should be -2.
because it's a float and not an int, it's strictly talking about integers here, not floats. All int conversions of floats are converted by discarding the remainder afaik but I could be wrong here (e.g. int(1.9) == 1, and int(-1.9) == -1)
edit: -3//2 == -2 for instance, since it's strictly integer division
Re: Why Python's integer division floors (2010)
#14Note 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.
I mean "inexact results" is essentially float's life motto.
That said, I don't really see why you would necessarily want float and integer division to behave the same. They're completely different types used for completely different things. Pick the one that is appropriate for your use case.
(It seems like abs(a % b) <= abs(b / 2) might be the right choice for floats which is pretty clearly not what you want for integers. I also just learned that integer division // can be applied to floats in Python, but the result is not an integer, for some reason?)
Re: Why Python's integer division floors (2010)
#15Yes that makes perfect sense. So why is int(-1.5) == -1? It should be -2.
There is math.floor for rounding towards negative infinity, which has the advantage of being crystal clear.
Re: Why Python's integer division floors (2010)
#16It should be noted that in C89, both behaviors of division and modulo are allowed and it's implementation-defined whether division results are truncated or rounded towards negative infinity. This has changed in C99 which only allows truncation towards zero.
Re: Why Python's integer division floors (2010)
#17Changing 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…
Very much this.
Re: Why Python's integer division floors (2010)
#18Changing 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…
A common approach (e.g. Cobol, Ada, Common Lisp, Haskell, Clojure, MATLAB, Julia, Kotlin) seems to be to provide two operators: One that uses truncated division, one that uses floored division. By convention, rem truncates, and mod floors.
Re: Why Python's integer division floors (2010)
#19Earlier quoted context omitted.
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.
My point is that Fortran doesn't have precedence on math, see this comment by Austin Feller :
http://python-history.blogspot.com/2010/08/why-pythons-integ...
Re: Why Python's integer division floors (2010)
#20Yes that makes perfect sense. So why is int(-1.5) == -1? It should be -2.
because it's a float and not an int, it's strictly talking about integers here, not floats. All int conversions of floats are converted by discarding the remainder afaik but I could be wrong here (e.g. int(1.9) == 1, and int(-1.9) == -1) edit: -3//2 == -2 for instance, since it's strictly integer division
It's a valid criticism: By the principle of least surprise, one should strive for a//b = int(a/b).
Basically, there's no free lunch. Personally, I prefer truncating integer division in combination with a pair of remainder operators.