<p>It appears that all of these operations can be performed in time <span class="math-container">$O(\log n/\log\log n)$</span> on a RAM, by combining methods for maintaining a dynamic labeling of the list elements by integers of polynomial magnitude (e.g. Bender et al, "Two Simplified Algorithms for Maintaining Order in a List", ESA 2002, <a href="https://erikdemaine.org/papers/DietzSleator_ESA2002/" rel="nofollow noreferrer">https://erikdemaine.org/papers/DietzSleator_ESA2002/</a>) with methods for ranking and unranking sets of small integers (Pătraşcu and Thorup, "Dynamic Integer Sets with Optimal Rank, Select, and Predecessor Search", FOCS 2014, <a href="https://arxiv.org/abs/1408.3045" rel="nofollow noreferrer">https://arxiv.org/abs/1408.3045</a>).</p>

<p>Operation 3 (get the value at a given position) is the simplest: it's just unranking. To insert or delete at a given position, use unranking to find which list element is there, do the insert or delete operations in your list at or near that element, use the order-maintenance structure to modify the numbering of elements, and then update the ranking-and-unranking data structure according to those modifications.</p>

<p><strong>Update 2020-05-25</strong>: Kasper Green Larsen emailed me the following lower bound proof and suggested I post it here:</p>

<p>We can prove the following lower bound: Let <span class="math-container">$t_u$</span> denote the update time and <span class="math-container">$t_q$</span> the query time of a data structure for the list problem. Both are worst case times. Then we have the following lower bounds (when the word size is logarithmic): If <span class="math-container">$t_u$</span> is polylog<span class="math-container">$(n)$</span>, then <span class="math-container">$t_q = \Omega(\log n/\log\log n)$</span>. If <span class="math-container">$t_q$</span> is polylog<span class="math-container">$(n)$</span>, then <span class="math-container">$t_u = \Omega(\log n/\log\log n)$</span>.</p>

<p>The proofs follow by reduction from 1-bit partial sums; see Pătraşcu and Demaine (SODA'04) [DE: See also Fredman and Henzinger, "Lower bounds for fully dynamic connectivity problems in graphs", Algorithmica 1998]. In 1-bit partial sums, we have a bit vector of length <span class="math-container">$n$</span>. An update flips the value of a bit. A query asks for the parity in a prefix of the array. In that paper, they prove exactly the above lower bounds for 1-bit partial sums, although their lower bound also holds if we change to amortized update and query time. The reduction I have loses that property (it can probably be fixed, see comment at the end). To give the reduction, we need to carefully examine the proof of Pătraşcu and Demaine to realize that their lower bound for partial sums holds even if the data structure is allowed to perform an arbitrary amount of preprocessing before seeing any updates or queries, as long as the word size is logarithmic, we have the lower bound (this observation is not necessary for the fix for amortized vs worst case). The initial input array in partial sums is all-0s and the sequence of operations for which they prove their lower bounds has only <span class="math-container">$n$</span> operations on the array.</p>

<p>We will reduce from 1-bit partial sums in an array of size <span class="math-container">$\sqrt n$</span> (and thus only <span class="math-container">$\sqrt n$</span> operations in the hard sequence) to the list problem in a list of up to <span class="math-container">$n$</span> elements. It goes as follows:
As a preprocessing step, set the list to contain <span class="math-container">$\sqrt n$</span> batches of the numbers <span class="math-container">$0,\dots,\sqrt{n} - 1$</span>, i.e. the list looks like:</p>

<p><span class="math-container">$$0,1,\dots,\sqrt{n}-1,0,1,\dots,\sqrt{n}-1,\dots,0,1,\dots,\sqrt{n}-1$$</span></p>

<p>with a total of <span class="math-container">$n$</span> elements.</p>

<p>Upon an update to flip the <span class="math-container">$i$</span>th bit of the partial sums array, we remove element <span class="math-container">$i \sqrt n$</span> from the list.</p>

<p>To compute the prefix sums up to index <span class="math-container">$i$</span> in the array, we retrieve element <span class="math-container">$i\sqrt n$</span> from the list and return its parity.</p>

<p>Let us see that the reduction works. First observe that before any updates are made to the list, a prefix sums query for an index <span class="math-container">$i$</span> will retrieve the "0" element in the <span class="math-container">$i$</span>th batch. Moreover, since we have only <span class="math-container">$\sqrt n$</span> operations, and all operations remove at most one element from the list, a prefix sums query for element <span class="math-container">$i$</span> will always retrieve an element that comes from the original <span class="math-container">$i$</span>th batch. Finally, observe that when we delete the <span class="math-container">$(i\sqrt n)$</span>th element of the list, all prefix sums queries for entries <span class="math-container">$j&lt;i$</span> are unaffected since the first part of the list doesn't change. Also, for all queries <span class="math-container">$j\ge i$</span>, we will now return the next element of the list since the list indices on or after <span class="math-container">$i\sqrt n$</span> all change by one. This next element will come from the same original batch and have a value one larger than before because we haven't deleted from this part of the original batch (this is where we use that we have <span class="math-container">$\sqrt n$</span> copies in each batch). Thus the answers to all queries <span class="math-container">$j\ge i$</span> correctly have their parity flipped.</p>

<p>The lower bound for 1-bit prefix sums on arrays of size <span class="math-container">$\sqrt n$</span> is the same as on arrays of size <span class="math-container">$n$</span> since <span class="math-container">$\log n$</span> only changes by a factor <span class="math-container">$2$</span>. Also, the lower bound holds even if we ignore all time that was spend during preprocessing, so we get our sought lower bound.</p>

<p>The reason why we lose the amortized lower bound is that we need to do <span class="math-container">$n$</span> initial operations to create the list. Thus even if we spend <span class="math-container">$\sqrt n$</span> time on each of the operations after preprocessing, the amortized time to process the whole sequence is only <span class="math-container">$O(1)$</span> per operation. This can probably be fixed as follows: Run <span class="math-container">$\sqrt n$</span> copies of the hard distribution for 1-bit partial sums, where after each sequence of <span class="math-container">$\sqrt n$</span> operations, we re-insert all elements that have been deleted. Then we get a total of <span class="math-container">$n$</span> updates and queries that all have a large amortized lower bound from 1-bit prefix sums. This is not completely formal, but I'm certain it can be formalized.</p>

CC BY-SA 4.0
2020-05-05T16:26:06.647Z
Thank you for this answer! 

The second paper even provides a lower bound on the complexity. The reverse relation to our problem is not direct but I will try to see if we cannot use it for our problem. I wouldn't be surprised if my problem has the same lower bound. I have other leads but if someone else has a link or an idea for the lower I am still interested!
Louis
CC BY-SA 4.0
2020-05-25T07:26:11.780Z
@Louis I've edited the answer to include a sort-of-matching lower bound. (Sort of because the upper bound is amortized and the lower bound is not.)
David Eppstein
CC BY-SA 4.0
2020-05-26T08:48:38.837Z
Thank you both. This is a very nice and detailed proof for the lower bound!
Louis
CC BY-SA 4.0
2020-05-01T00:27:07.480Z
2020-05-25T07:28:01.853Z
2020-05-25T07:28:01.853Z
David Eppstein
<p>I understand you may only be interested in purely theoretical answers, but all theory are based on an underlying model. If your model is that all memory can be addressed in O(1) time, then these alternative data structure are of interest.</p>

<p>Otherwise, I always advise people to use arrays. If you need to add items, add them at the end in O(1) time. If you need them ordered, then sort the array, but only afterward, once it has been filled. Similarly, if you need to remove elements, it is better to wait to do it in batch. IOW, accumulate linearly elements (or their indices) to be deleted in another array. Then recreate the original array in a new one by linear insertion at the end, skipping the elements to be removed. (And then sort, if needed.)</p>

<p>The main error to be done is to design algorithms to work on a single element at a time and analyze complexity at the single-element operation level. Doing operations in batches, processing the maximum number of items linearly is better, 99% of the time.</p>

CC BY-SA 4.0
2020-05-26T08:56:48.783Z
Thank you for your answer. I have thought about this and it actually lead me to a second problem (that I include here even it might not interest you but it is a subproblem of your solution):

You are given a list of size n, you are given n updates (insert value or delete at position k) and you need to compute the new list after all these updates. What is the time needed to process the updates?

Note that this is not trivial because all the updates shift the positions for later updates. It can be done in  $O(n \times \dfrac{ln(n)}{lnln(n)})$ (see above) but can we do better ? ...
Louis
CC BY-SA 4.0
2020-05-11T22:19:52.893Z
2020-05-11T22:19:52.893Z
pierrebai
<p>I am interested in the complexity of a data-structure equipped with the following operations (similar to a list):</p>

<ol>
<li>insertion of an element at a given position within the list</li>
<li>deletion of an element at a given position within the list</li>
<li>get the value of an element at a given position within the list</li>
</ol>

<p>For instance "insert <span class="math-container">$v_3$</span> at position 3"; modifies the list <span class="math-container">$e_1 e_2 e_3 e_4$</span>
into <span class="math-container">$e_1 e_2 v_3 e_3 e_4$</span> and "delete at position 4" would produce the list <span class="math-container">$e_1 e_2 v_3 e_4$</span>.</p>

<p>Obviously a list can be used to answer all these questions but with a <span class="math-container">$O(n)$</span> complexity for all three operations. We can also use an array to have 3. with <span class="math-container">$O(1)$</span> complexity but with <span class="math-container">$O(n)$</span> complexity for 1. and 2. Finally we can use a balanced tree structure to get all three operations in <span class="math-container">$O(\ln(n))$</span>. Is there any other known structure that achieves an interesting compromise?</p>

<p>A second but related question: If the operation 3. is limited to retrieve the value of the first element, can we do any better than this? Of course for this a list achieves <span class="math-container">$O(n)$</span> for 1. and 2. but <span class="math-container">$O(1)$</span> for the first element. With a bit of modification I think we can make the array-based solution work in <span class="math-container">$O(n)$</span> for deletion of the first element but <span class="math-container">$O(1)$</span> for everything else. With the balanced tree approach we can make <span class="math-container">$O(\ln(n))$</span> for 2. and 3. and <span class="math-container">$O(1)$</span> for 1. Are there any structure with a better compromise here?</p>

<p>Finally a third (and last) question, when 3. is limited to ask for the first element, what is the best that can be achieved for the sum of the complexities of 1., 2. and 3.? Are there any known lower bounds for this? Is there a better upper bound than <span class="math-container">$O(\ln(n))$</span>?</p>

CC BY-SA 4.0
2020-05-02T02:51:18.060Z
For your last question, notice that the sum of the three complexities is $\Theta($ the max $)$.
usul
<ds.algorithms><complexity><machine-models>
On the complexity of a "list" datastructure in the RAM model
Louis
# On the complexity of a "list" datastructure in the RAM model

(Asked by: username_0 on 2020-04-29)

I am interested in the complexity of a data-structure equipped with the following operations (similar to a list):

1. insertion of an element at a given position within the list
2. deletion of an element at a given position within the list
3. get the value of an element at a given position within the list

For instance "insert $v\_3$ at position 3"; modifies the list $e\_1 e\_2 e\_3 e\_4$
into $e\_1 e\_2 v\_3 e\_3 e\_4$ and "delete at position 4" would produce the list $e\_1 e\_2 v\_3 e\_4$.

Obviously a list can be used to answer all these questions but with a $O(n)$ complexity for all three operations. We can also use an array to have 3. with $O(1)$ complexity but with $O(n)$ complexity for 1. and 2. Finally we can use a balanced tree structure to get all three operations in $O(\ln(n))$. Is there any other known structure that achieves an interesting compromise?

A second but related question: If the operation 3. is limited to retrieve the value of the first element, can we do any better than this? Of course for this a list achieves $O(n)$ for 1. and 2. but $O(1)$ for the first element. With a bit of modification I think we can make the array-based solution work in $O(n)$ for deletion of the first element but $O(1)$ for everything else. With the balanced tree approach we can make $O(\ln(n))$ for 2. and 3. and $O(1)$ for 1. Are there any structure with a better compromise here?

Finally a third (and last) question, when 3. is limited to ask for the first element, what is the best that can be achieved for the sum of the complexities of 1., 2. and 3.? Are there any known lower bounds for this? Is there a better upper bound than $O(\ln(n))$?

**Tags:** ds.algorithms, complexity, machine-models

> **Comments:**
> **username_1**: For your last question, notice that the sum of the three complexities is $\Theta($ the max $)$.  

---

## 2 answers

### Answer by username_2 on 2020-05-01. Score: 7 | Accepted answer

It appears that all of these operations can be performed in time $O(\log n/\log\log n)$ on a RAM, by combining methods for maintaining a dynamic labeling of the list elements by integers of polynomial magnitude (e.g. Bender et al, "Two Simplified Algorithms for Maintaining Order in a List", ESA 2002, <https://erikdemaine.org/papers/DietzSleator_ESA2002/>) with methods for ranking and unranking sets of small integers (Pătraşcu and Thorup, "Dynamic Integer Sets with Optimal Rank, Select, and Predecessor Search", FOCS 2014, <https://arxiv.org/abs/1408.3045>).

Operation 3 (get the value at a given position) is the simplest: it's just unranking. To insert or delete at a given position, use unranking to find which list element is there, do the insert or delete operations in your list at or near that element, use the order-maintenance structure to modify the numbering of elements, and then update the ranking-and-unranking data structure according to those modifications.

**Update 2020-05-25**: Kasper Green Larsen emailed me the following lower bound proof and suggested I post it here:

We can prove the following lower bound: Let $t\_u$ denote the update time and $t\_q$ the query time of a data structure for the list problem. Both are worst case times. Then we have the following lower bounds (when the word size is logarithmic): If $t\_u$ is polylog$(n)$, then $t\_q = \Omega(\log n/\log\log n)$. If $t\_q$ is polylog$(n)$, then $t\_u = \Omega(\log n/\log\log n)$.

The proofs follow by reduction from 1-bit partial sums; see Pătraşcu and Demaine (SODA'04) [DE: See also Fredman and Henzinger, "Lower bounds for fully dynamic connectivity problems in graphs", Algorithmica 1998]. In 1-bit partial sums, we have a bit vector of length $n$. An update flips the value of a bit. A query asks for the parity in a prefix of the array. In that paper, they prove exactly the above lower bounds for 1-bit partial sums, although their lower bound also holds if we change to amortized update and query time. The reduction I have loses that property (it can probably be fixed, see comment at the end). To give the reduction, we need to carefully examine the proof of Pătraşcu and Demaine to realize that their lower bound for partial sums holds even if the data structure is allowed to perform an arbitrary amount of preprocessing before seeing any updates or queries, as long as the word size is logarithmic, we have the lower bound (this observation is not necessary for the fix for amortized vs worst case). The initial input array in partial sums is all-0s and the sequence of operations for which they prove their lower bounds has only $n$ operations on the array.

We will reduce from 1-bit partial sums in an array of size $\sqrt n$ (and thus only $\sqrt n$ operations in the hard sequence) to the list problem in a list of up to $n$ elements. It goes as follows:
As a preprocessing step, set the list to contain $\sqrt n$ batches of the numbers $0,\dots,\sqrt{n} - 1$, i.e. the list looks like:

$$0,1,\dots,\sqrt{n}-1,0,1,\dots,\sqrt{n}-1,\dots,0,1,\dots,\sqrt{n}-1$$

with a total of $n$ elements.

Upon an update to flip the $i$th bit of the partial sums array, we remove element $i \sqrt n$ from the list.

To compute the prefix sums up to index $i$ in the array, we retrieve element $i\sqrt n$ from the list and return its parity.

Let us see that the reduction works. First observe that before any updates are made to the list, a prefix sums query for an index $i$ will retrieve the "0" element in the $i$th batch. Moreover, since we have only $\sqrt n$ operations, and all operations remove at most one element from the list, a prefix sums query for element $i$ will always retrieve an element that comes from the original $i$th batch. Finally, observe that when we delete the $(i\sqrt n)$th element of the list, all prefix sums queries for entries $j are unaffected since the first part of the list doesn't change. Also, for all queries $j\ge i$, we will now return the next element of the list since the list indices on or after $i\sqrt n$ all change by one. This next element will come from the same original batch and have a value one larger than before because we haven't deleted from this part of the original batch (this is where we use that we have $\sqrt n$ copies in each batch). Thus the answers to all queries $j\ge i$ correctly have their parity flipped.

The lower bound for 1-bit prefix sums on arrays of size $\sqrt n$ is the same as on arrays of size $n$ since $\log n$ only changes by a factor $2$. Also, the lower bound holds even if we ignore all time that was spend during preprocessing, so we get our sought lower bound.

The reason why we lose the amortized lower bound is that we need to do $n$ initial operations to create the list. Thus even if we spend $\sqrt n$ time on each of the operations after preprocessing, the amortized time to process the whole sequence is only $O(1)$ per operation. This can probably be fixed as follows: Run $\sqrt n$ copies of the hard distribution for 1-bit partial sums, where after each sequence of $\sqrt n$ operations, we re-insert all elements that have been deleted. Then we get a total of $n$ updates and queries that all have a large amortized lower bound from 1-bit prefix sums. This is not completely formal, but I'm certain it can be formalized.

> **Comments:**
> **username_0**: Thank you for this answer!   The second paper even provides a lower bound on the complexity. The reverse relation to our problem is not direct but I will try to see if we cannot use it for our problem. I wouldn't be surprised if my problem has the same lower bound. I have other leads but if someone else has a link or an idea for the lower I am still interested!  
> **username_2**: @username_0 I've edited the answer to include a sort-of-matching lower bound. (Sort of because the upper bound is amortized and the lower bound is not.)  
> **username_0**: Thank you both. This is a very nice and detailed proof for the lower bound!  

---

### Answer by username_3 on 2020-05-11. Score: 0

I understand you may only be interested in purely theoretical answers, but all theory are based on an underlying model. If your model is that all memory can be addressed in O(1) time, then these alternative data structure are of interest.

Otherwise, I always advise people to use arrays. If you need to add items, add them at the end in O(1) time. If you need them ordered, then sort the array, but only afterward, once it has been filled. Similarly, if you need to remove elements, it is better to wait to do it in batch. IOW, accumulate linearly elements (or their indices) to be deleted in another array. Then recreate the original array in a new one by linear insertion at the end, skipping the elements to be removed. (And then sort, if needed.)

The main error to be done is to design algorithms to work on a single element at a time and analyze complexity at the single-element operation level. Doing operations in batches, processing the maximum number of items linearly is better, 99% of the time.

> **Comments:**
> **username_0**: Thank you for your answer. I have thought about this and it actually lead me to a second problem (that I include here even it might not interest you but it is a subproblem of your solution):  You are given a list of size n, you are given n updates (insert value or delete at position k) and you need to compute the new list after all these updates. What is the time needed to process the updates?  Note that this is not trivial because all the updates shift the positions for later updates. It can be done in  $O(n \times \dfrac{ln(n)}{lnln(n)})$ (see above) but can we do better ? ...  

---

