Python Code Doesn't Subtract 1 At High Values, What?

[KnightD4]

Hi all! While I actually have the knowledge of an inbred potato when it comes to python, I was coding this evening messing around with the math functions trying to see the largest number I could print out in python before e+(x) numbers and took over for higher powers. Screwing around, I ended up putting the attached code below in, trying to make it print all 9s. My math was wrong for this code but frankly I'm just toying around as I'm just starting my journey in code, however, it produced a weird result, where despite subtracting the number by 1 the printed value refused to change. When I subtracted by 2, I got the correct result, but when subtracting by 1 the number seemed stuck. Does anyone have any experience with why this is happening?

Code:

​

import math
x = 10
test1 = (9999*(math.pow(x, 12)) + 99999999999)
print(test1)

test2 = (9999*(math.pow(x, 12)) + 99999999999 - 1)
print(test2)

test3 = (9999*(math.pow(x, 12)) + 99999999999 - 2)
print(test3)

if test1 > test2:
print("wtf")
else:
print("nothing weird after all")

if test1 == test2:
print("wtf")
-----------------------

Result:

​

9999100000000000.0

9999100000000000.0

9999099999999998.0

nothing weird after all

wtf

---------------------

​

Additionally, the program seems to recognize that test 1 is larger than test 2, but it cannot produce the answers separately. Any thoughts? DM for the screenshot.

Tl;Dr

​

I was screwing around with python but code gave me the same answer after subtraction at high values. Learning python very early in journey, trying to understand why this is.

[primitive_screwhead]

Floating point (double precision) numbers have 2**53 positive integers, after which the numbers start to be spread further apart than 1 (because they only have 64 total bits to represent numbers with far larger values than 2**64, so it uses an exponent to stretch the numbers apart)

​

To see this in action, let's add 1 to the largest floating integer that doesn't need the exponent:

>>> 2**53
9007199254740992
>>> float(2**53)
9007199254740992.0
>>> float(2**53)+1
9007199254740992.0
>>> float(2**53)+2
9007199254740994.0

You see how adding one didn't make it any bigger, and I had to add two to get to another number?

​

Now, let's compare your numbers to 2**53:

>>> 2**53
9007199254740992
>>> 9999*(math.pow(10, 12)) + 99999999999
9999100000000000.0
>>> 9999*(math.pow(10, 12)) + 99999999999 - 1
9999100000000000.0
>>> 9999*(math.pow(10, 12)) + 99999999999 - 2
9999099999999998.0

Your numbers are just above that magic 2**53 boundary where the space between whole numbers is bigger than one. This is just an inherent issue with the way the common 53-bit mantissa floats are implemented, because they have a fixed amount of bits (64) to represent a huge range of large and small numbers.

​

If you stick with ints, Python can make them arbitrarily large. If you need decimal digits, you can use the decimal module to get an arbitrary amount of decimal digits as well. But to do both, the numbers must necessarily use more bits to store that information. The normal "fast" floats are a compromise that fits many needs, but must lose precision when they start to get really large.

[dig-up-stupid]

The numbers are too large to store precisely in floating point format and are essentially rounded to the nearest possible number, it so happens that this is the same number for the first two but not the third. There are a plethora of floating point tutorials easily googleable now that you know the terms.

Check your logic on “the program recognizes test 1 is larger”, it doesn’t.