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

41–50 of 102 posts

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

#41

Post by DonHopkins »

kragen wrote: post #22
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.

mentioned in the comments on the post, which merit reading in this case i haven't read the rationale, but presumably the committee did this because it's what virtually all cpus do (because it's what fortran does), so it's the only thing that can be implemented efficiently on virtually any cpu with a division instruction, and so virtually all c implementations did it, and standardizing the behavior of virtually all c…

Who would have ever thought that division could be so ... divisive?

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

#42

Post by kragen »

DonHopkins wrote: post #41
kragen wrote: post #22

Earlier quoted context omitted.

mentioned in the comments on the post, which merit reading in this case i haven't read the rationale, but presumably the committee did this because it's what virtually all cpus do (because it's what fortran does), so it's the only thing that can be implemented efficiently on virtually any cpu with a division instruction, and so virtually all c implementations did it, and standardizing the behavior of virtually all c…

Who would have ever thought that division could be so ... divisive?

as sophie w. arm said, 'i have a multiplier, not a divider'

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

#43

Post by pclmulqdq »

pansa2 wrote: post #5

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

In an abstract sense, floating-point division is a fundamentally different operation than integer division. There is not generally expected to be a remainder fron floating-point division aside from 0.5 ULP that will be rounded away.

If you use it without considering rounding modes carefully and then round to integer, you can get some funny results.

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

#46

Post by kragen »

Aardwolf wrote: post #44

They made the correct decision here! Too bad they made the wrong decision in not supporting the expected floating point behavior of division through zero (python throwing errors, rather than return inf or nan)

in https://stackoverflow.com/questions/78064239/does-python-not... it seems like ieee 754 does permit throwing errors on division by zero, and although it isn't the default behavior on any hardware i've used, the name of unix's division-by-zero exception signal strongly suggests that it's also the default behavior on the (non-ieee-754-compliant) pdp-11. https://stackoverflow.com/questions/12954193/why-does-divisi... makes the opposite assertion, though that ieee 754 does not permit division by zero traps. i'm not sure what to believe

people commonly opt out of python's behavior in this case by using numpy

python's decision is maybe suboptimal for efficient compilation, but it has a lot of decisions like that

edit: downthread https://news.ycombinator.com/item?id=39540416 pclmulqdq clarifies that in fact trapping on division by zero is not only ieee-754-compliant but (unlike flooring integer division!) efficiently implementable on common high-performance architectures

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

#47

Post by notso411 »

Eiim wrote: post #45
notso411 wrote: post #8

How many integer 2s go in to 7? 3 not 4.. Not a hard question to answer.

Did you read the article? It's about what happens in negative numbers. Of course everyone agrees that 7/2=3 in integer division, but -7/2 is less obvious.

[dead]

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

#48

Post by DonHopkins »

kragen wrote: post #42
DonHopkins wrote: post #41

Earlier quoted context omitted.

Who would have ever thought that division could be so ... divisive?

as sophie w. arm said, 'i have a multiplier, not a divider'

At the RISC of sounding short on instructions, do you mean Sophie Wilson's ARM? ;)

https://en.wikipedia.org/wiki/Sophie_Wilson

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

#49

Post by pclmulqdq »

kragen wrote: post #46
Aardwolf wrote: post #44

They made the correct decision here! Too bad they made the wrong decision in not supporting the expected floating point behavior of division through zero (python throwing errors, rather than return inf or nan)

in https://stackoverflow.com/questions/78064239/does-python-not... it seems like ieee 754 does permit throwing errors on division by zero, and although it isn't the default behavior on any hardware i've used, the name of unix's division-by-zero exception signal strongly suggests that it's also the default behavior on the (non-ieee-754-compliant) pdp-11. https://stackoverflow.com/questions/12954193/why-does-divisi...…

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.

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

#50

Post by kragen »

pclmulqdq wrote: post #49
kragen wrote: post #46

Earlier quoted context omitted.

in https://stackoverflow.com/questions/78064239/does-python-not... it seems like ieee 754 does permit throwing errors on division by zero, and although it isn't the default behavior on any hardware i've used, the name of unix's division-by-zero exception signal strongly suggests that it's also the default behavior on the (non-ieee-754-compliant) pdp-11. https://stackoverflow.com/questions/12954193/why-does-divisi...…

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.

there's a whole set of terminology about 'exceptions', 'traps', and 'signaling' in ieee 754 that i don't really understand, but in particular the second thread i linked there seems to claim that an ieee 754 'exception' is almost, but not quite, completely unlike a python 'exception', which it apparently calls a 'trap' (as do many cpu architectures):

> When exceptional situations need attention, they can be examined immediately via traps or at a convenient time via status flags. Traps can be used to stop a program, but unrecoverable situations are extremely rare.

you know quite a bit about cpus. do you know of any ieee-754 cpus that trap on floating-point division by zero by default? is there a way to configure commonly-used cpus to do so?

Post reply on HN