What happens when large integers are involved?

  • Thread starter Thread starter PeroK
  • Start date Start date
  • Tags Tags
    Integers Python
AI Thread Summary
The discussion highlights issues with integer arithmetic when dealing with large numbers in Python, particularly focusing on the incorrect results from using the division operator (/), which defaults to floating-point arithmetic. Users are advised to utilize integer division (//) or the Fraction class to avoid rounding errors. Python 3 can handle arbitrarily large integers, so the problem is not related to integer size limits but rather the choice of division operator. The conversation also touches on the differences in behavior between Python 2.x and 3.x regarding division. For those needing arbitrary precision arithmetic, Sage is recommended as a useful tool.
PeroK
Science Advisor
Homework Helper
Insights Author
Gold Member
2024 Award
Messages
29,093
Reaction score
20,717
TL;DR Summary
Arithmetic error handling large integer in Python
I've written a program to factorise large numbers (although not that large). The following arithmetic operation goes wrong:

x= int(912_321_155_211_368_155/(5))

The result is

182_464_231_042_273_632

Which is clearly not right (should end in 631). The maximum integer on the 64-bit version is supposed to be larger than that.

How do you know when integer arithmetic is getting too large and things start to go wrong?
 
Last edited:
Technology news on Phys.org
It looks like it is using 64 bit double precision floating point which will give you 16 digits. You might be able to force it to use 16 bit unsigned integer.
Also arrays of digits can be used.
 
  • Like
Likes PeroK
Baluncore said:
It looks like it is using 64 bit double precision floating point which will give you 16 digits. You might be able to force it to use 16 bit unsigned integer.
I'll assume the limit is 16 digits.

To go beyond that, do you have to hand-crank the arithmetic? Just program long division myself?
 
No, there is a long integer library you must find.
 
Baluncore said:
No, there is a long integer library you must find.
No, there is no long integer library in Python 3 because it should automatically upgrade 'ordinary' integers.
 
@PeroK what version do you use?
 
PeroK said:
x= int(912_321_155_211_368_155/(5))
Baluncore said:
It looks like it is using 64 bit double precision floating point which will give you 16 digits.
The / operator is a floating point operator. Integer division is // (since 2.something)
 
  • Like
Likes Wrichik Basu, FactChecker, PeroK and 1 other person
pbuk said:
The / operator is a floating point operator. Integer division is // (since 2.something)
That's fixed it. Thanks.
 
PeroK said:
I've written a program to factorise large numbers (although not that large). The following arithmetic operation goes wrong:

x= int(912_321_155_211_368_155/(5))

To avoid floating point rounding errors, either use integer division, i.e., the // operator, if you know the quotient is an exact integer, as has already been suggested, or use the Fraction class from the fractions module, which can represent fractions exactly without using floating point and risking rounding errors.

Another option to extract integer quotients is the divmod built-in function, which gives you an integer quotient and remainder.

PeroK said:
The result is

182_464_231_042_273_632

Which is clearly not right (should end in 631). The maximum integer on the 64-bit version is supposed to be larger than that.

The issue here has nothing to do with any maximum integer size. Python can represent arbitrarily large integers; it's not limited by the bit width of the underlying platform.
 
  • Like
Likes PeroK
  • #10
Baluncore said:
You might be able to force it to use 16 bit unsigned integer.
That wouldn't help -- the largest unsigned 16-bit integer is 65, 535.
 
  • Haha
Likes pbuk
  • #11
The / and // operators can cause some curious side effects when porting code from 2.7 python to 3.x python.

The / in python 2.x returns integer answers when the operands are both integers and return float answers when one or both operands are floats.

2 / 3 returns 0

5 / 2 returns 2

Programmers familiar with this behavior using python 2.x would tend to use / over //.

One common use for the integer / operator was when computing indices for data records in binary random store files.

I ran into this very bug as I converted a program from C to python 2.x which worked and then to python 3.x which didn't. It was tracked down to the / vs // issue.

https://stackoverflow.com/questions/183853/what-is-the-difference-between-and-when-used-for-division
 
  • #12
Sage (https://www.sagemath.org/) will do arbitrary precision arithmetic. It is an easy add-on to Python, and runs in Jupyter notebooks.

Code:
factor(12345678910111213141516171819202122232425262728293031323334353637383940)
2^2 * 5 * 3169 * 60757 * 579779 * 4362289433 * 79501124416220680469 * 15944694111943672435829023
 
  • Like
Likes PeroK
Back
Top