Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Python's integer division floors (2010)

python-history.blogspot.com

Post reply on HN
Print view View original

91–100 of 102 posts

Re: Why Python's integer division floors (2010)

#91

Post by im3w1l »

lalaithion wrote: post #81
taeric wrote: post #62

I confess I have grown increasingly in favor of how common lisp does this. The basic `/` creates rationals. And "floor" is a multiple value return where the first value is the floor and the second is the remainder. Granted, getting used to multiple value calls takes getting used to. I think I like it, but I also think I emphatically did not like it initially.

To be fair, Python's `/` creates floats, and this article is about a second operator `//`.

In python 2, '/' creates integers, and the article was written in 2010 when python 2 was the most used by far.

Re: Why Python's integer division floors (2010)

#93

Post by kazinator »

rcfox wrote: post #85
kazinator wrote: post #84

Earlier quoted context omitted.

However, the oposite shift is undefined if a 1 goes into the sign bit. More precisely, regarding E1 "If E1 has a signed type and nonnegative value, and E1 × 2ᴱ² is representable in the result type, then that is the resulting value; otherwise, the behavior is undefined." Thus if E1 is negative, or if the result overflows, UB.

Didn't they specify two's complement signed integers somewhat recently? What's the rationale for leaving these behaviours undefined?

Because the shift operations are arithmetically defined, and the situations that are undefined correspond to overflow. v << 1 means the same thing as v * 2 and is undefined if v * 2 is undefined.

Re: Why Python's integer division floors (2010)

#94

Post by lalaithion »

im3w1l wrote: post #91
lalaithion wrote: post #81

Earlier quoted context omitted.

To be fair, Python's `/` creates floats, and this article is about a second operator `//`.

In python 2, '/' creates integers, and the article was written in 2010 when python 2 was the most used by far.

from the link:

> PS. Note that I am using // instead of / -- this is Python 3 syntax

Re: Why Python's integer division floors (2010)

#95

Post by im3w1l »

lalaithion wrote: post #94
im3w1l wrote: post #91

Earlier quoted context omitted.

In python 2, '/' creates integers, and the article was written in 2010 when python 2 was the most used by far.

from the link: > PS. Note that I am using // instead of / -- this is Python 3 syntax

Oh. Right.

Re: Why Python's integer division floors (2010)

#97

Post by chubot »

marcosdumay wrote: post #83
Karellen wrote: post #32

Earlier quoted context omitted.

I've always considered it a mistake to refer to "%" as a "modulo" operator in C because of its ability to return negative numbers. That's not how modulo arithmetic works. C's "%" is a remainder operator.

That's not any clearer. Both "modulo" and "remainder" can be defined in ways (yeah, more than one) that include or exclude negative numbers. You have to memorize the full definition. There's no mnemonic shortcut.

Remainder goes with division, and respects invariants

Modulus doesn’t. I believe that algebraically equality module N can exist without division

Re: Why Python's integer division floors (2010)

#98

Post by shikon7 »

marko_oktabyr wrote: post #77
Karellen wrote: post #32

Earlier quoted context omitted.

I've always considered it a mistake to refer to "%" as a "modulo" operator in C because of its ability to return negative numbers. That's not how modulo arithmetic works. C's "%" is a remainder operator.

> That's not how modulo arithmetic works. We should be a bit careful with what one means by "modulo arithmetic" here. If we are talking about arithmetic in Z/nZ (read "integers modulo n"), then the objects being acted upon are no longer integers, but equivalence classes of integers. That is, the set of all integers that satisfy the equivalence relation "~" where "a ~ b" means a - b = k*n for some integer k. For examp…

But 2 mod 3 should still give the same as -1 mod 3. If the representative for the same equivalence class is allowed to be different depending on the input, you could just as well use the number itself.

Re: Why Python's integer division floors (2010)

#99

Post by marko_oktabyr »

shikon7 wrote: post #98
marko_oktabyr wrote: post #77

Earlier quoted context omitted.

> That's not how modulo arithmetic works. We should be a bit careful with what one means by "modulo arithmetic" here. If we are talking about arithmetic in Z/nZ (read "integers modulo n"), then the objects being acted upon are no longer integers, but equivalence classes of integers. That is, the set of all integers that satisfy the equivalence relation "~" where "a ~ b" means a - b = k*n for some integer k. For examp…

But 2 mod 3 should still give the same as -1 mod 3. If the representative for the same equivalence class is allowed to be different depending on the input, you could just as well use the number itself.

At the risk of being snarky, I should certainly hope the output depends on the input.

On a more serious note, there are quite reasonable properties that are satisfied by keeping the sign of the first argument as the chosen representative. In particular, for any two nonzero integers a and b, we have that:

a = (a / b) * b + (a mod b)

Where division should be interpreted as integer division that rounds towards zero. If a=-1 and b=3, then (a/b) would be zero which would require (a mod b) to be -1 if we want the above to hold. Also note that other rounding choices (e.g., rounding towards negative infinity) could impose (a mod b) = 2.

So choosing a particular representative comes down to choosing what properties you want your function to have in relation to other arithmetic.

Re: Why Python's integer division floors (2010)

#100

Post by oasisaimlessly »

marko_oktabyr wrote: post #99
shikon7 wrote: post #98

Earlier quoted context omitted.

But 2 mod 3 should still give the same as -1 mod 3. If the representative for the same equivalence class is allowed to be different depending on the input, you could just as well use the number itself.

At the risk of being snarky, I should certainly hope the output depends on the input. On a more serious note, there are quite reasonable properties that are satisfied by keeping the sign of the first argument as the chosen representative. In particular, for any two nonzero integers a and b, we have that: a = (a / b) * b + (a mod b) Where division should be interpreted as integer division that rounds towards zero. If…

There is no "particular representative"; every equivalence class (except 0) has two possible representatives.

... and that's exactly why the C modulo operator sucks.

Post reply on HN