Maximum and Minimum values for ints
Note that in Python 3 the int type is basically the same as the long type in Python 2, so the idea of a maximum or minimum int disappears completely. It’s basically irrelevant even on Python 2.
@agf: it can be relevant in various way. For instance in any algorithm that require to save the min value found (like a sorting algorithm). The min value could be initialized at sys.maxint so it guarantees that any first value found is taken as min
@Toaster except that you can have a list where all values are greater than sys.maxint since it’s only the maximum for the int type on Python 2, which Python will silently promote to a long .
If you need to use «a very large value» in an algorithm, e.g. finding minimum or maximum of a generic collection, float(‘inf’) or float(‘-inf’) can be quite helpful.
@geoff true, but one caveat for modern code is that floats can’t be used as Literal in type hints. So you can’t say that a list can contain Union[int, Literal[-inf]] even though that might be exactly what might be needed for a given application :/
11 Answers 11
Python 3
In Python 3, this question doesn’t apply. The plain int type is unbounded.
However, you might actually be looking for information about the current interpreter’s word size, which will be the same as the machine’s word size in most cases. That information is still available in Python 3 as sys.maxsize , which is the maximum value representable by a signed word. Equivalently, it’s the size of the largest possible list or in-memory sequence.
Generally, the maximum value representable by an unsigned word will be sys.maxsize * 2 + 1 , and the number of bits in a word will be math.log2(sys.maxsize * 2 + 2) . See this answer for more information.
Python 2
In Python 2, the maximum value for plain int values is available as sys.maxint :
>>> sys.maxint # on my system, 2**63-1 9223372036854775807 You can calculate the minimum value with -sys.maxint — 1 as shown in the docs.
Python seamlessly switches from plain to long integers once you exceed this value. So most of the time, you won’t need to know it.
This number may appear to be arbitrary, but it isn’t. 9223372036854775807 is exactly 2^63 — 1 , so you’ve got a 64-bit int. In general, an n-bit integer has values ranging from -2^(n-1) to 2^(n-1) — 1 .
Note that if you’re using a 32-bit Python runtime, sys.maxint will return 2^31 — 1 , even though Python will jump to 64-bit seamlessly with the long datatype.
Use sys.maxsize instead, as suggested by @Akash Rana. It is present also in Python 2, as sys docs say. This will make the code more compatible with both Python versions.
You and I have different interpretations of that line from the docs. The replacement in 2to3 is a fine quick-and-dirty heuristic that won’t break anything most of the time — but the difference between these two values matters. The best practice is to use the value you actually mean to use. If you truly need sys.maxint in Python 2, you won’t need it anymore in Python 3, and it should really be removed entirely, not changed to sys.maxsize .
If you just need a number that’s bigger than all others, you can use
in similar fashion, a number smaller than all others:
This works in both python 2 and 3.
Just a note tho (as irrelevant it is, but still): float(‘inf’) > float(‘inf’) results in ‘false’. Infinite number should be bigger than another infinite number 😀 . mind snaps
@Scre What else would you expect? x > x is usually False , and infinity should be no exception. ( float(‘NaN) , on the other hand. )
This actually doesn’t apply for int cauze cannot convert infinite float to int . but works for most cases
@Scre «In comparison operations, positive infinity is larger than all values except itself and NaN, and negative infinity is smaller than all values except itself and NaN.» gnu.org/software/libc/manual/html_node/Infinity-and-NaN.html
The sys.maxint constant has been removed from Python 3.0 onward, instead use sys.maxsize .
Integers
- PEP 237: Essentially, long renamed to int . That is, there is only one built-in integral type, named int ; but it behaves mostly like the old long type.
- The sys.maxint constant was removed, since there is no longer a limit to the value of integers. However, sys.maxsize can be used as an integer larger than any practical list or string index. It conforms to the implementation’s “natural” integer size and is typically the same as sys.maxint in previous releases on the same platform (assuming the same build options).
Correct. Indeed, from help(sys) : maxsize — the largest supported length of containers. This should be the accepted answer.
I guess that the correct answer depends on the use case: in my casa (a default for a limiting parameter in a function) this was indeed the best answer, YMMV.
For Python 3, there is no maximum or minimum value for the int type.
You might be interested in sys.maxsize instead. According to the documentation:
sys.maxsize
An integer giving the maximum value a variable of type Py_ssize_t can take. It’s usually 2**31 — 1 on a 32-bit platform and 2**63 — 1 on a 64-bit platform.
import sys max_size = sys.maxsize min_size = -sys.maxsize - 1 well, python 3 does exist , thankfully(!); but sys.maxint doesn’t exist in python 3 (tl;dr: » sys.maxint constant was removed (in python3), since there is no longer a limit to the value of integers. However, sys.maxsize can be used as an integer larger than any practical list or string index.» )
This answer is false. If it were true sys.maxsize ** 2 would not return a valid and correct value, yet it does. You should delete this answer.
These would work great as sentinel values in algorithms, which is a common usage. Please don’t delete this answer, just make it clear that it’s the most practical one, even if not the most mathematically correct one.
In Python 2, integers will automatically switch from a fixed-size int representation into a variable width long representation once you pass the value sys.maxint , which is either 2 31 — 1 or 2 63 — 1 depending on your platform. Notice the L that gets appended here:
>>> 9223372036854775807 9223372036854775807 >>> 9223372036854775808 9223372036854775808L Numbers are created by numeric literals or as the result of built-in functions and operators. Unadorned integer literals (including binary, hex, and octal numbers) yield plain integers unless the value they denote is too large to be represented as a plain integer, in which case they yield a long integer. Integer literals with an ‘L’ or ‘l’ suffix yield long integers ( ‘L’ is preferred because 1l looks too much like eleven!).
Python tries very hard to pretend its integers are mathematical integers and are unbounded. It can, for instance, calculate a googol with ease:
>>> 10**100 10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000L In python3, seems there is no L suffix, and it’s just int , not long , no matter how large the number is.
may i suggest editing your answer showing type(. ) instead on relying on an L at the end which an have ambiguous meaning?
You may use ‘inf’ like this:
The author questioned how to obtain the MAX and MIN int values. How does this answer relates to the question, since the results are True and False, not MAX and MIN?
If you want the max for array or list indices (equivalent to size_t in C/C++), you can use numpy:
This is same as sys.maxsize however advantage is that you don’t need import sys just for this.
If you want max for native int on the machine:
You can look at other available types in doc.
For floats you can also use sys.float_info.max .
sys.maxsize is not the actually the maximum integer value which is supported. You can double maxsize and multiply it by itself and it stays a valid and correct value.
However, if you try sys.maxsize ** sys.maxsize , it will hang your machine for a significant amount of time. As many have pointed out, the byte and bit size does not seem to be relevant because it practically doesn’t exist. I guess python just happily expands it’s integers when it needs more memory space. So in general there is no limit.
Now, if you’re talking about packing or storing integers in a safe way where they can later be retrieved with integrity then of course that is relevant. I’m really not sure about packing but I know python’s pickle module handles those things well. String representations obviously have no practical limit.
So really, the bottom line is: what is your applications limit? What does it require for numeric data? Use that limit instead of python’s fairly nonexistent integer limit.