Integers take up logarithmic space but this is usually of little interest during algorithmic analysis of real-world problems.
Here are things to keep in mind:
1. Not the same $n$
The $n$ often used in Big-O notation conventionally refers to the number of data items, rather than the possible range of those items. For example, if you are sorting 50000 integers and they are all smaller than 2 billion, that's $n=50000$ and $m=2000000000$. The input data will consume $O(n\,\text{log}\,m$) space. But often this will just be expressed as $O(n)$ because in the real world it's rarely important to consider mind-bogglingly-huge integers which is what it would take to make a serious difference here.
2. Most algorithms are comparably affected by datum size
One of the main reasons to perform asymptotic analysis is to compare two algorithms which solve the same problem. Most important classes of algorithm, such as sorting and searching and graph algorithms (e.g. shortest-path etc.) and optimisation algorithms, generally have the same asymptotic complexity whether they are operating on say 32 or 64 bits.
3. There are exceptions
If we consider things like very large prime number testing, the size of the primes can be crucial to accurately characterise an algorithm's behaviour.
Also, in abstract or theoretical environments it is necessary to be more rigorous about such things. Turing Machines typically have a fairly small alphabet (i.e. "variables" can hold a quite small range of values) so it is impossible to hand-wave away the size of an int
.
4. Many languages use variable-sized integers by default
In Python, Ruby, Haskell and Raku, an integer is automatically allocated as much memory as it needs. You can multiply 999999999 * 999999999 * 999999999 * 999999999
in any of these languages and get a 100% precise result—they are not floating-point numbers. So if you create an array of really big integers you will see logarithmic memory usage. (CPU operations will also increase if the numbers are larger!)
5. In practice, integer size (or numerical precision generally) is usually about machine selection, not algorithm selection.
If you are trying to process 20-digit numbers on an 8-bit computer, you are using the wrong machine. You will experience a blowout of both RAM and CPU operations. The solution is not a change of algorithm but a change of hardware.
6. Sparse integers can usually be collapsed with e.g. hashing
Algorithms that require several copies of very large integers to be stored can be modified to save memory by hashing the datum or using indices/pointers. This step does not increase big-O performance complexity (although it does slow things down.) Figuring out the right trade-off to make is not really something that can be captured in a simple big-O formula.
memory position
used by your professor has no units specified explicitly, but intuitively by using the common meaning, it can thought asmemory word
which is actually measured in bits. In real world computers all the data types likeint, float, double
have a fixed data size and as such the bits required to store them are constant and taking this constant number of bits as amemory position
, your professor explains. $\endgroup$n
. So it states that to store an integer of sizen
we need $\Theta(\lg n)$ no. of bits. Note the units, and the concept that here the size of the bits required to represent an integer is not bounded , rather it is allowed to be variable with respect ton
$\endgroup$