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

71–80 of 102 posts

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

#71

Post by pclmulqdq »

hawski wrote: post #66
pclmulqdq wrote: post #49

Earlier quoted context omitted.

IEEE 754 has an infinity, so division by zero isn't the catastrophic thing that it is in integer. However, division by zero is still an exception as defined by the 754 standard. What hardware does with these exceptions is a separate question, though. Some CPUs will swallow them for performance.

IEEE 754 has infinity, it has signed zeros, but it doesn't have the absolute zero. For the math to be entirely correct it is not enough. I wonder why it was done like this.

+/-0 should generally be thought of as 0. It's just "0 from the right" and "0 from the left." The reason it has +/-0 is for a few specific applications:

- Some people really do want 1/(-x) to be negative infinity when a positive x reaches underflow. This helps with some kinds of numerical simulations since it can preserve the sign bit through underflow.

- Interval arithmetic implementations need to be able to disambiguate closed and open intervals at 0.

If you turn on fast math mode, you can also essentially disable the special treatment of the zeros.

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

#72

Post by Karellen »

pwdisswordfishc wrote: post #61
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.

Exactly. Modulo is not an operator, but a term for an equivalence class of differing by a multiple of a number fixed in advance.

> Modulo is not an operator,

"operator" is being used as a term of art in programming language design, to describe a symbol used to indicate that an operation should be performed on one or more operands.

https://en.wikipedia.org/wiki/Operator_(computer_programming...

So the "%" symbol is an operator in C and Python, and it is standard usage to describe the operator that performs a mathematical function "X" as the "X operator".

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

#73

Post by hawski »

pclmulqdq wrote: post #71
hawski wrote: post #66

Earlier quoted context omitted.

IEEE 754 has infinity, it has signed zeros, but it doesn't have the absolute zero. For the math to be entirely correct it is not enough. I wonder why it was done like this.

+/-0 should generally be thought of as 0. It's just "0 from the right" and "0 from the left." The reason it has +/-0 is for a few specific applications: - Some people really do want 1/(-x) to be negative infinity when a positive x reaches underflow. This helps with some kinds of numerical simulations since it can preserve the sign bit through underflow. - Interval arithmetic implementations need to be able to disambi…

But still, why there is no absolute 0 - the third zero? I would prefer something like this:

  1 / +0 == +inf
  1 / -0 == -inf
  1 / 0 == nan
  abs(-0) == 0
But it is not possible as there is no unsigned/absolute zero: 0 means +0. I guess it makes things much simpler, but IMHO it makes it a bit less useful and strange.

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

#74

Post by marko_oktabyr »

pwdisswordfishc wrote: post #61
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.

Exactly. Modulo is not an operator, but a term for an equivalence class of differing by a multiple of a number fixed in advance.

As sibling comments have mentioned, "operator" here is being used in the programming language sense of the word, not the mathematical sense. Using the name "mod" [as in mod(a,n)] or "modulo" for the mapping that takes integers to a particular representative of its equivalence class in Z/nZ ("integers modulo n") doesn't seem like an unreasonable choice to me.

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

#75

Post by pclmulqdq »

hawski wrote: post #73
pclmulqdq wrote: post #71

Earlier quoted context omitted.

+/-0 should generally be thought of as 0. It's just "0 from the right" and "0 from the left." The reason it has +/-0 is for a few specific applications: - Some people really do want 1/(-x) to be negative infinity when a positive x reaches underflow. This helps with some kinds of numerical simulations since it can preserve the sign bit through underflow. - Interval arithmetic implementations need to be able to disambi…

But still, why there is no absolute 0 - the third zero? I would prefer something like this: 1 / +0 == +inf 1 / -0 == -inf 1 / 0 == nan abs(-0) == 0 But it is not possible as there is no unsigned/absolute zero: 0 means +0. I guess it makes things much simpler, but IMHO it makes it a bit less useful and strange.

I think if you treat infinity as a special case of NaN (which it basically is for many math systems), you get the behavior you want. A lot of people think that +/-0 represent +/-epsilon, but they really don't. +0 is the default 0, and -0 is what you get when you underflow specifically from the left.

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

#76

Post by matsemann »

Karellen wrote: post #32
nwellnhof wrote: post #16

It 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.

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.

I have to re-learn this each year for Advent of Code, when inevitable my something % anything goes into the negative when searching downwards.

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

#77

Post by marko_oktabyr »

Karellen wrote: post #32
nwellnhof wrote: post #16

It 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.

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 example, one of the equivalence classes in Z/3Z would be the set {..., -4, -1, 2, 5, ...}.

Since every element of the set is equivalent under that relation, we typically will choose a representative of that equivalence class, e.g., [2] for the previous class. If we view the "mod" or "modulo" operator to be a mapping from the integers to a particular representative of its equivalence class, there's no reason that negative values should be excluded. [-1] refers to the same equivalence class as [2], [32], and [-7]. The details of how integers are mapped to a chosen representative seem to vary from language to language, but modular arithmetic works all the same between them.

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

#78

Post by kstrauser »

rightbyte wrote: post #59
kstrauser wrote: post #51

Earlier quoted context omitted.

I am soooo glad that Python throws errors there. Instead of being surprised when your math starts giving unexpected results, it blows up and makes you deal with the error. There's no situation where I'd prefer silent incorrectness.

Inf is not incorrect. Division by the two almost zero numbers will also give "unexpected" results, if inf is unexpected.

You're right about the unexpected results in that case, but I'd bet good money that accidentally dividing by zero in code like `avg=sum(lst)/len(lst)` is far more common in standard Python code than dividing very small numbers.

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

#79

Post by mik1998 »

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.

It's nice for general numerical methods but somewhat annoying for implementing integer-arithmetic algorithms.

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

#80

Post by kazinator »

Karellen wrote: post #32
nwellnhof wrote: post #16

It 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.

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.

Under modulo math, -1, 9 and 19, for example, are all the same element of the modulo 10 congruence. 9 is called the "least positive residue", which is sometimes important.
Post reply on HN