What happens when large integers are involved?

[PeroK]

TL;DR

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?

 

[Baluncore]

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.

 

[PeroK]

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?

 

[Baluncore]

No, there is a long integer library you must find.

 

[pbuk]

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.

 

[Baluncore]

@PeroK what version do you use?

 

[pbuk]

x= int(912_321_155_211_368_155/(5))

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)

 

[PeroK]

The / operator is a floating point operator. Integer division is // (since 2.something)

That's fixed it. Thanks.

 

[PeterDonis]

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.

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.

 

[Mark44]

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.

 

[jedishrfu]

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

 

[phyzguy]

Sage (https://www.sagemath.org/) will do arbitrary precision arithmetic. It is an easy add-on to Python, and runs in Jupyter notebooks.

factor(12345678910111213141516171819202122232425262728293031323334353637383940)
2^2 * 5 * 3169 * 60757 * 579779 * 4362289433 * 79501124416220680469 * 15944694111943672435829023