7

Why is sys.maxint < (sys.maxint - 100 + 0.01) in Python?

Improve this question

3 Answers 3

Reset to default
12

This is probably due to loss of precision for very large floating point values. (the adding of 0.01 converts the right-hand-side to float).

Edit: I have tried to come up with an exact explanation of what happens here, but to no avail. So I posted a question about it.

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

Precisely. See also the output of int(sys.maxint - 100 + 0.01) on 64-bit: 9223372036854775808L (instead of ...807L)
Except for Windows 64 bit machines where sys.maxint always is 2**32/2-1 because the long type is only 32 bits signed.
@Space_C0wb0y, what do you mean by loose 11 bits of precision, are those 11 bits set to zero or some random bit string?
@Saturo: I am not exactly sure (my explanation is more of a guess), but since the bits are just truncated, it is as if they were 0, so the result is lower than the actual number.
@Satoru Logic: He meant lose, not loose. Those 11 bits can't be "set" to anything, they don't exist. You have 64 precision passengers to fit on a approx-53 precision-passenger bus. 11 passengers miss out. Those 11 bit positions in a float (still a 64-seat bus) are used for the exponent and sign bit. Note that the leading precision bit in a float is 1 by definition and thus doesn't need a seat.
|
3

On a system with 64-bit longs, sys.maxint is:

// decimal hexadecimal 9223372036854775807 0x7fffffffffffffff

So sys.maxint - 100 is:

 9223372036854775707 0x7fffffffffffff9b

Adding 0.01 forces this value to be rounded to double-precision floating point before the addition. The two closest values that are representable in double-precision are:

 9223372036854774784 0x7ffffffffffffc00 9223372036854775808 0x8000000000000000

Because sys.maxint - 100 is closer to the second (larger) value, it rounds up. Adding 0.01 gives:

 9223372036854775808.01 0x8000000000000000.028f5c28f5c...

which is not representable in double-precision, so it is rounded again, to:

 9223372036854775808 0x8000000000000000

So the value of sys.maxint - 100 + 0.01 is actually larger than the value of sys.maxint. However, in many modern languages, comparison between an integer and a float forces the integer value to be converted to floating point before the comparison takes place; if this were the case in python, sys.maxint would be rounded up to the same value, and they would compare equal. It seems that this is not the case in Python. I'm not familiar with the details of python numerics, but this is an interesting curiosity of the language.

Improve this answer

2 Comments

You are right, assert float(sys.maxint) > (sys.maxint - 100 + 0.01)
You're correct: Python goes out of its way to give correct results for mixed-type comparisons. Without this, Python containers (sets, dicts) would be in trouble, since the == relation is used to determine container membership.
3

at least on my machine it is not

In [7]: import sys In [8]: sys.maxint < (sys.maxint - 100 + 0.01) Out[8]: False
Improve this answer

1 Comment

Needs 64-bit to see it, on 32-bit the number is too small for the float to lose the necessary amount of precision.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.