Why is the time complexity of Python's list.append() method O(1)?
Question:
As seen in the documentation for TimeComplexity, Python’s list type is implemented using an array.
So if an array is being used and we do a few appends, eventually you will have to reallocate space and copy all the information to the new space.
After all that, how can it be O(1) worst case?
Answers:
If you look at the footnote in the document you linked, you can see that they include a caveat:
These operations rely on the “Amortized” part of “Amortized Worst
Case”. Individual actions may take surprisingly long, depending on the
history of the container.
Using amortized analysis, even if we have to occasionally perform expensive operations, we can get a lower bound on the ‘average’ cost of operations when you consider them as a sequence, instead of individually.
So, any individual operation could be very expensive – O(n) or O(n^2) or something even bigger – but since we know these operations are rare, we guarantee that a sequence of O(n) operations can be done in O(n) time.
It’s amortized O(1), not O(1).
Let’s say the list reserved size is 8 elements and it doubles in size when space runs out. You want to push 50 elements.
The first 8 elements push in O(1).
The nineth triggers reallocation and 8 copies, followed by an O(1) push.
The next 7 push in O(1).
The seventeenth triggers reallocation and 16 copies, followed by an O(1) push.
The next 15 push in O(1).
The thirty-third triggers reallocation and 32 copies, followed by an O(1) push.
The next 31 push in O(1). This continues as the size of list is doubled again at pushing the 65th, 129th, 257th element, etc..
So all of the pushes have O(1) complexity, we had 64 copies at O(1), and 3 reallocations at O(n), with n = 8, 16, and 32. Note that this is a geometric series and asymptotically equals O(n) with n = the final size of the list. That means the whole operation of pushing n objects onto the list is O(n). If we amortize that per element, it’s O(n)/n = O(1).
This is very easy.
We can calculate this by accumulating the total time of appending n elements into an arraylist and divide it by n.
Firstly, we need to relocate log(n) times, and every relocation is doubled by 2. So we have a proportional series whose ratio is 2, and the length is log(n).
The sum of a proportional series is a(1-r^n)/(1-r).
So the total time of relocation is (1-n)/(1-2)=n.
The time complexity would be n/n=1.
As seen in the documentation for TimeComplexity, Python’s list type is implemented using an array.
So if an array is being used and we do a few appends, eventually you will have to reallocate space and copy all the information to the new space.
After all that, how can it be O(1) worst case?
If you look at the footnote in the document you linked, you can see that they include a caveat:
These operations rely on the “Amortized” part of “Amortized Worst
Case”. Individual actions may take surprisingly long, depending on the
history of the container.
Using amortized analysis, even if we have to occasionally perform expensive operations, we can get a lower bound on the ‘average’ cost of operations when you consider them as a sequence, instead of individually.
So, any individual operation could be very expensive – O(n) or O(n^2) or something even bigger – but since we know these operations are rare, we guarantee that a sequence of O(n) operations can be done in O(n) time.
It’s amortized O(1), not O(1).
Let’s say the list reserved size is 8 elements and it doubles in size when space runs out. You want to push 50 elements.
The first 8 elements push in O(1).
The nineth triggers reallocation and 8 copies, followed by an O(1) push.
The next 7 push in O(1).
The seventeenth triggers reallocation and 16 copies, followed by an O(1) push.
The next 15 push in O(1).
The thirty-third triggers reallocation and 32 copies, followed by an O(1) push.
The next 31 push in O(1). This continues as the size of list is doubled again at pushing the 65th, 129th, 257th element, etc..
So all of the pushes have O(1) complexity, we had 64 copies at O(1), and 3 reallocations at O(n), with n = 8, 16, and 32. Note that this is a geometric series and asymptotically equals O(n) with n = the final size of the list. That means the whole operation of pushing n objects onto the list is O(n). If we amortize that per element, it’s O(n)/n = O(1).
This is very easy.
We can calculate this by accumulating the total time of appending n elements into an arraylist and divide it by n.
Firstly, we need to relocate log(n) times, and every relocation is doubled by 2. So we have a proportional series whose ratio is 2, and the length is log(n).
The sum of a proportional series is a(1-r^n)/(1-r).
So the total time of relocation is (1-n)/(1-2)=n.
The time complexity would be n/n=1.