Order maintenance problem

List-labeling

A problem related to the order-maintenance problem is the list-labeling problem in which instead of the order(X, Y) operation the solution must maintain an assignment of labels from a universe of integers { 1 , 2 , … , u } to the elements of the set such that X precedes Y in the total order if and only if X is assigned a lesser label than Y. It must also support an operation label(X) returning the label of any node X. Note that order(X, Y) can be implemented simply by comparing label(X) and label(Y) so that any solution to the list-labeling problem immediately gives one to the order-maintenance problem. In fact, most solutions to the order-maintenance problem are solutions to the list-labeling problem augmented with a level of data structure indirection to improve performance. We will see an example of this below.

For efficiency, it is desirable for the size u of the universe be bounded in the number of elements n stored in the data structure. In the case where u is required to be linear in n the problem is known as the packed-array maintenance or dense sequential file maintenance problem. Consider the elements as entries in a file and the labels as giving the addresses where each element is stored. Then an efficient solution to the packed-array maintenance problem would allow efficient insertions and deletions of entries into the middle of a file with no asymptotic space overhead. This usage has recent applications in cache-oblivious data structures and optimal worst-case in-place sorting.

However, under some restrictions, Ω ( log 2 ⁡ n ) lower bounds have been found on the performance of insertion in solutions of the list-labeling problem with linear universes whereas we will see below that a solution with a polynomial universe can perform insertions in O ( log ⁡ n ) time.

List-labeling and binary search trees

List-labeling in a universe of size polynomial in the number n of elements in the total order is connected to the problem of maintaining balance in a binary search tree. Note that every node X of a binary search tree is implicitly labeled with an integer that corresponds to its path from the root of the tree. We call this integer the path label of X and define it as follows. Let σ be the sequence of left and right descents in this path. For example, σ = ( left , right , right ) if X is the right child of the right child of the left child of the root of the tree. Then X is labeled with the integer whose base 3 representation is given by replacing every occurrence of left in σ with 0, replacing every occurrence of right in σ with 2 and appending 1 to the end of the resulting string. Then in the previous example, the path label of X is 0221₃ which is equal to 25 in base 10. Note that path labels preserve tree-order and so can be used to answer order queries in constant time.

If the tree has height h then these integers come from the universe { 1 , 2 , … , 3 h + 1 − 2 } . Then if the tree is self-balancing so that it maintains a height no greater than c log ⁡ n then the size of the universe is polynomial in n .

Therefore, the list-labeling problem can be solved by maintaining a balanced binary search tree on the elements in the list augmented with path labels for each node. However, since every rebalancing operation of the tree would have to also update these path labels, not every self-balancing tree data structure is suitable for this application. Note, for example, that rotating a node with a subtree of size k , which can be done in constant time under usual circumstances, requires Ω ( k ) path label updates. In particular, if the node being rotated is the root then the rotation would take time linear in the size of the whole tree. With that much time the entire tree could be rebuilt. We will see below that there are self-balancing binary search tree data structures that cause an appropriate number of label updates during rebalancing.

Data structure

The list-labeling problem can be solved with a universe of size polynomial in the number of elements n by augmenting a scapegoat tree with the path labels described above. Scapegoat trees do all of their rebalancing by rebuilding subtrees. Since it takes Ω ( k ) time to rebuild a subtree of size k , relabeling that subtree in O ( k ) time after it is rebuilt does not change the asymptotic performance of the rebalancing operation.

Order

Given two nodes X and Y, order(X, Y) determines their order by comparing their path labels.

Insert

Given a new node for X and a pointer to the node Y, insert(X, Y) inserts X immediately after Y in the usual way. If a rebalancing operation is required, the appropriate subtree is rebuilt, as usual for a scapegoat tree. Then that subtree is traversed depth first and the path labels of each of its nodes is updated. As described above, this asymptotically takes no longer than the usual rebuilding operation.

Delete

Deletion is performed similarly to insertion. Given the node X to be deleted, delete(X) removes X as usual. Any subsequent rebuilding operation is followed by a relabeling of the rebuilt subtree.

Analysis

It follows from the argument above about the rebalancing performance of a scapegoat tree augmented with path labels that the insertion and deletion performance of this data structure are asymptotically no worse than in a regular scapegoat tree. Then, since insertions and deletions take O ( log ⁡ n ) amortized time in scapegoat trees, the same holds for this data structure.

Furthermore, since a scapegoat tree with parameter α maintains a height of at most log 1 / α ⁡ n + 1 , the path labels have size at most 3 log 1 / α ⁡ n + 2 − 2 ≤ 9 n 1 log 3 ⁡ ( 1 / α ) . For the typical value of α = 2 3 then the labels are at most 9 n 3 .

Of course, the order of two nodes can be determined in constant time by comparing their labels. A closer inspection shows that this holds even for large n . Specifically, if the word size of the machine is w bits, then typically it can address at most 2 w nodes so that n < 2 w . It follows that the universe has size at most 9 ⋅ 2 3 w and so that the labels can be represented with a constant number of (at most 4 + 3 w ) bits.

Lower bound on list-labeling

It has been shown that any solution to the list-labeling problem with a universe polynomial in the number of elements will have insertion and deletion performance no better than Ω ( log ⁡ n ) . Then, for list-labeling, the above solution is asymptotically optimal. Incidentally, this also proves an Ω ( log ⁡ n ) lower bound on the amortized rebalancing time of an insertion or deletion in a scapegoat tree.

However, this lower bound does not apply to the order-maintenance problem and, as stated above, there are data structures that give worst-case constant time performance on all order-maintenance operations.

O(1) amortized insertion via indirection

Indirection is a technique used in data structures in which a problem is split into multiple levels of a data structure in order to improve efficiency. Typically, a problem of size n is split into n / log ⁡ n problems of size log ⁡ n . For example, this technique is used in y-fast tries. This strategy also works to improve the insertion and deletion performance of the data structure described above to constant amortized time. In fact, this strategy works for any solution of the list-labeling problem with O ( log ⁡ n ) amortized insertion and deletion time.

The new data structure is completely rebuilt whenever it grows too large or too small. Let N be the number of elements of the total order when it was last rebuilt. The data structure is rebuilt whenever the invariant N 3 ≤ n ≤ 2 N is violated by an insertion or deletion. Since rebuilding can be done in linear time this does not affect the amortized performance of insertions and deletions.

During the rebuilding operation, the N elements of the total order are split into O ( N / log ⁡ N ) contiguous sublists, each of size Ω ( log ⁡ N ) . A path-labeled scapegoat tree is constructed on a set of nodes representing each of the sublists in their original list order. For each sublist a doubly-linked list of its elements is built storing with each element a pointer to its representative in the tree as well as a local integer label. These local labels are independent of the labels used in the tree and are used to compare any two elements of the same sublist. The elements of a sublist are given the local labels log ⁡ N , 2 log ⁡ N , … , log 2 ⁡ N , … , in their original list order.

Order

Given the sublist nodes X and Y, order(X, Y) can be answered by first checking if the two nodes are in the same sublist. If so, their order can be determined by comparing their local labels. Otherwise the path labels of their representatives in the tree are compared. This takes constant time.

Insert

Given a new sublist node for X and a pointer to the sublist node Y, insert(X, Y) inserts X immediately after Y in the sublist of Y. If X is inserted at the end of the sublist, it is given the local label ℓ ( Y ) + log ⁡ N , where ℓ ( Y ) is the local label of Y; otherwise, if possible, it is labeled with the floor of the average of the local labels of its two neighbours. This easy case takes constant time.

In the hard case, the neighbours of X have contiguous local labels and the sublist has to be rebuilt. However, in this case at least log ⁡ N − 1 elements have been added to the sublist since it was first built. Then we can afford to spend a linear amount of time in the size of the sublist to rebuild it and possibly split it into smaller sublists without affecting the amortized cost of insertion by any more than a constant.

If the sublist has size k then we split it into O ( k / log ⁡ N ) contiguous sublists of size O ( log ⁡ N ) , locally labeling each new sublist as described above and pointing each element of a sublist to a new representative node to be inserted into the tree. It takes O ( k ) time to construct the sublists. Since we do not allow empty sublists, there are at most n ≤ 2 N of them and so a representative can be inserted into the tree in O ( log ⁡ N ) time. Hence, it takes O ( k ) time to insert all of the new representatives into the tree.

Delete

Given a sublist node X to be deleted, delete(X) simply removes X from its sublist in constant time. If this leaves the sublist empty, then we need to remove the representative of the sublist from the tree. Since at least Ω ( log ⁡ N ) elements were deleted from the sublist since it was first built we can afford to spend the O ( log ⁡ N ) time it takes to remove the representative without affecting the amortized cost of deletion by any more than a constant.