In Chapter 5 of Purely Functional Data Structures, Okasaki introduces the amortization analysis as preparation for the complexity analysis of functional data structures.

The idea of amortized analysis is to prove the complexity of an operation when the average cost per operation is less than the worst case cost of each individual operation.

In this post we’ll perform analysis of 2 data structures and show that their amortized running time is much better than their worst case. There are 2 methods presented in the book, the **Banker’s Method** and the **Physicist Method**. I found the Physicist easier to work with, so I’ll only use that. Also, I find it easy to understand concepts with an examples, so we’ll first introduce the data structure and then introduce the analysis.

### Queue with lists

An easy way to implement the queue data structure is by using two lists, one representing the beginning (left) and the other the end (right). Inserting/removing an element from the beginning of a list in OCaml is O(1), while doing it at the end is O(n). For this reason, we store the end of the queue reversed in the right list. (In imperative languages the opposite is true, insertions/removals at the end are O(1) and at the beginning O(n), so the left array that is reversed).

Insertions are performed by appending an element to the beginning of the right array. Removing from the front of the queue requires removing the first element of the left array. When the left array is empty, we need to reverse the contents of the right array and move it to the left.

We work with an invariant, in which the left array is only empty if the right array is empty as well. That requires a slight change to the removal, where we perform the reversal and move of the right array when the left array has only one element and is about to become empty.

I’ve implemented this idea in Ocaml.

### Analysis – The Physicist Method

If we only look at the worst case, we will get that removing from a queue is an O(n) operation. We can improve this by looking at the amortized cost. One way to perform this analysis is via the **physicist method**, in which we define a potential (or cost) function for the data structure . In the queue case, we can define it to be the size of the right list.

The amortized cost of step i, is defined by

Where is the actual cost (in number of operations)

The intuition is that some costly operations such as reversing the list, which takes O(n) operations, can only happen after O(n) insertions happened, so the average cost per operation is O(1). Translating it to the potential analogy, each insersion operation increases the potential of the data structure by 1, so by the time a revert happens, the right list is emptied and that causes a loss of potential of n, which had been accumulated and that offsets the cost of the operation .

We can get the accumulated amortized cost of the operations up to a specific step by summing them, and we’ll get

If we choose such that , for all i, then A_i is an upper bound of . Since we assume is the empty queue, and we have , this property is satisfied.

One important remark is that this analysis is only applicable to non-persistent data structures, which is not the case in OCaml. We present the OCaml code as exercise, but the correct analysis will done in later chapters.

### Splay Trees

Splay Tree is a binary search tree. The insertion of an element `e`

consists in spliting the current tree in 2 subtrees, one of all elements less or equal than `e`

, which we’ll call small and another will all elements larger than `e`

, which we’ll call big. We then make `e`

the root of tree and small the left subtree and big the right subtree.

The partition operation is O(height of tree). The intuition is, when looking for the small subtree, imagine we’re analysing a node `x`

. If `x >= e`

, then we know all elements in the left subtree are also `>= e`

, so are all the elements in the right subtree, so we can discard it and only look at the left subtree. The same idea applies to looking for the big subtree.

In an ideal scenario, the tree will be well balanced in such a way that the height of the tree is O(log n), and so the insertion operation. But that’s not always the case, so we introduce a balancing strategy. Whenever we follow 2 lefts in a row when searching for the big subtree, we perform a right rotation. Similarly, when following 2 rights in a row when searching for the small subtree, we perform a left rotation.

These re-balancing are enough to make partition and also insertion an O(log n) amortized time, as we shall see in the next section.

The operation for finding the minimum element is trivial. To delete the minimum element, we also perform rotations. Since we only traverse the left paths, we only have to do a left rotation.

I’ve implemented these ideas in OCaml.

### Amortized Analysis of Splay Trees

We first define a potential function. Given a tree and a node , let be the subtree of rooted in . Then be a potential function where the number of nodes of the subtree of which is root, and let the potential of a tree , , be the sum of the sub-potentials of all nodes of , that is,

(1) .

The amortized equation of calling `partition()`

is the actual cost of the partition, plus the potential of the resulting trees (small and big) minus the potential of the original tree. Let’s denote `small(t)`

as , and `big(t)`

as .

(2)

We can prove that (see appendix), which means the amortized cost of the partition operation is . It implies that insertion also has an amortized cost of .

The same idea can be used to prove the amortized costs of the deletion of the minimum element. Okasaki claims that splay trees are one of the fastest implementations for heaps when persistence is not needed.

### Conclusion

I found amortized analysis very hard to grasp. My feeling is that the amortized analysis is too abstracted from the real problem, making it not very intuitive. It’s also not clear how one picks the potential function and whether there’s a choice of potential that might result in a better than the “actual” amortized cost.

### Appendix

As we can see in code, there are four cases to consider: left-left, left-right, right-left and right-right. The left-* and right-* are symmetric, so let’s focus on the left-left and left-right cases. For the left-left case, suppose we perform the following partition:

We start with (2)

(3)

Since corresponds to the number of recursive calls to partition, , so

(4)

The recursive call to u yields (s’, b’), so we have the equivalence, ,

(5)

Since, s = s’,

(6)

and , and , we can cancel out some terms and simplify the equation above to

(7)

by induction, ,

(8)

Since is a subtree of , and since the nodes in is a subset of t,

(9)

It’s possible to show that, given such that , then . We have that , while , thus, and by the relation above, , , which yields

(10) .

It’s very subtle, but in this last step we used the assumption of the rotation, in particular in , if we hadn’t performed the rotation, , and wouldn’t hold!

For the left-right case, we can do a similar analysis, except that now we’ll apply the recursion to , and the resulting partition will look different, as depicted below:

In this case, (8) will become

(11)

We then use that and this will allow us to cancel out some terms to

(12)

Similar to what we've done before, we can show that since the partitions of are mutually exclusive. We can still use the result from the other case and get (10).

### References

[1] Wikipedia – Amortized Analysis