Solutions to Integer Overflow

Re:Solutions to Integer Overflow by Dylan16807 on Saturday September 03, 2016 @05:14AM (#12418451)

That's not a literal. The result of an expression that overflows int is a long. 'int' is merely an efficient way of storing small integers as part of the larger bignum scheme.

  >>> z=2**62
  >>> type(z)
  <type 'int'>
  >>> type(z+z)
  <type 'long'>

[ Parent | on HN ]

Re:Solutions to Integer Overflow by justinlardinois on Saturday September 03, 2016 @07:20AM (#12418771)

Point taken. So if I'm understanding right, Python 2 converts int to long when necessary, whereas in Python 3 int is already a long to begin with.

[ Parent | on HN ]

Re:Solutions to Integer Overflow by Dylan16807 on Saturday September 03, 2016 @07:52AM (#12418846)

The distinction is probably still there but slightly more hidden from view. It's a good optimization, no reason to throw it out.

It would take some prodding around to find out.

[ Parent | on HN ]

Re:Solutions to Integer Overflow by __s on Saturday September 03, 2016 @08:45AM (#12418985)

All python ints/longs are boxed (there's a cache for like -5 to 256). The interpreter often checks if the digit count is 1, in which case it can fall into basic integer addition of C. This is an implementation detail tho; if I do type(x) I shouldn't have to check for both int & long. So they store that information as part of the object type, rather than in the type of the object

In the past some have implemented tagged integers for Python, good benchmarking results but the devs argue 'Good Python code should be more symbolic; it shouldn't be doing too much integer math' which also comes up where the interpreter doesn't implement specialized code for floats, instead they argue that if you need fast floating point you should be using numpy or a C extension

Tagged ints: https://mail.python.org/pipermail/python-dev/2004-July/04613...

[ Parent | on HN ]