10.1 BinaryHeap: An Implicit Binary Tree

Our first implementation of a (priority) Queue is based on a technique that is over four hundred years old. Eytzinger's method allows us to represent a complete binary tree as an array by laying out the nodes of the tree in breadth-first order (see Section 6.1.2). In this way, the root is stored at position 0, the root's left child is stored at position 1, the root's right child at position 2, the left child of the left child of the root is stored at position 3, and so on. See Figure 10.1.

Figure 10.1: Eytzinger's method represents a complete binary tree as an array.

If we apply Eytzinger's method to a sufficiently large tree, some patterns emerge. The left child of the node at index $\ensuremath{\ensuremath{\mathit{i}}}$ is at index $\ensuremath{\ensuremath{\mathrm{left}(\ensuremath{\mathit{i}})}}=2\ensuremath{\ensuremath{\ensuremath{\mathit{i}}}}+1$ and the right child of the node at index $\ensuremath{\ensuremath{\mathit{i}}}$ is at index $\ensuremath{\ensuremath{\mathrm{right}(\ensuremath{\mathit{i}})}}=2\ensuremath{\ensuremath{\ensuremath{\mathit{i}}}}+2$. The parent of the node at index $\ensuremath{\ensuremath{\mathit{i}}}$ is at index $\ensuremath{\ensuremath{\mathrm{parent}(\ensuremath{\mathit{i}})}}=(\ensuremath{\ensuremath{\ensuremath{\mathit{i}}}}-1)/2$.

A BinaryHeap uses this technique to implicitly represent a complete binary tree in which the elements are heap-ordered: The value stored at any index $\ensuremath{\ensuremath{\mathit{i}}}$ is not smaller than the value stored at index $\ensuremath{\mathrm{parent}(\ensuremath{\mathit{i}})}$, with the exception of the root value, $\ensuremath{\ensuremath{\ensuremath{\mathit{i}}}}=0$. It follows that the smallest value in the priority Queue is therefore stored at position 0 (the root).

In a BinaryHeap, the $\ensuremath{\ensuremath{\mathit{n}}}$ elements are stored in an array $\ensuremath{\ensuremath{\mathit{a}}}$:

Implementing the $\ensuremath{\mathrm{add}(\ensuremath{\mathit{x}})}$ operation is fairly straightforward. As with all array-based structures, we first check to see if $\ensuremath{\ensuremath{\mathit{a}}}$ is full (by checking if $\ensuremath{\ensuremath{\mathrm{length}(\ensuremath{\mathit{a}})}}=\ensuremath{\ensuremath{\ensuremath{\mathit{n}}}}$) and, if so, we grow $\ensuremath{\ensuremath{\mathit{a}}}$. Next, we place $\ensuremath{\ensuremath{\mathit{x}}}$ at location $\ensuremath{\ensuremath{\mathit{a}}[\ensuremath{\mathit{n}}]}$ and increment $\ensuremath{\ensuremath{\mathit{n}}}$. At this point, all that remains is to ensure that we maintain the heap property. We do this by repeatedly swapping $\ensuremath{\ensuremath{\mathit{x}}}$ with its parent until $\ensuremath{\ensuremath{\mathit{x}}}$ is no longer smaller than its parent. See Figure 10.2.

Figure 10.2: Adding the value 6 to a BinaryHeap.

Implementing the $\ensuremath{\mathrm{remove}()}$ operation, which removes the smallest value from the heap, is a little trickier. We know where the smallest value is (at the root), but we need to replace it after we remove it and ensure that we maintain the heap property.

The easiest way to do this is to replace the root with the value $\ensuremath{\ensuremath{\mathit{a}}[\ensuremath{\mathit{n}}-1]}$, delete that value, and decrement $\ensuremath{\ensuremath{\mathit{n}}}$. Unfortunately, the new root element is now probably not the smallest element, so it needs to be moved downwards. We do this by repeatedly comparing this element to its two children. If it is the smallest of the three then we are done. Otherwise, we swap this element with the smallest of its two children and continue.

Figure 10.3: Removing the minimum value, 4, from a BinaryHeap.

As with other array-based structures, we will ignore the time spent in calls to $\ensuremath{\mathrm{resize}()}$, since these can be accounted for using the amortization argument from Lemma 2.1. The running times of both $\ensuremath{\mathrm{add}(\ensuremath{\mathit{x}})}$ and $\ensuremath{\mathrm{remove}()}$ then depend on the height of the (implicit) binary tree. Luckily, this is a complete binary tree; every level except the last has the maximum possible number of nodes. Therefore, if the height of this tree is $h$, then it has at least $2^h$ nodes. Stated another way

$$\ensuremath{\ensuremath{\ensuremath{\mathit{n}}}} \ge 2^h \enspace .$$

Taking logarithms on both sides of this equation gives

$$h \le \log \ensuremath{\ensuremath{\ensuremath{\mathit{n}}}} \enspace .$$

Therefore, both the $\ensuremath{\mathrm{add}(\ensuremath{\mathit{x}})}$ and $\ensuremath{\mathrm{remove}()}$ operation run in $O(\log \ensuremath{\ensuremath{\ensuremath{\mathit{n}}}})$ time.

10.1.1 Summary

The following theorem summarizes the performance of a BinaryHeap:

Theorem 10..1   A BinaryHeap implements the (priority) Queue interface. Ignoring the cost of calls to $\ensuremath{\mathrm{resize}()}$, a BinaryHeap supports the operations $\ensuremath{\mathrm{add}(\ensuremath{\mathit{x}})}$ and $\ensuremath{\mathrm{remove}()}$ in $O(\log \ensuremath{\ensuremath{\ensuremath{\mathit{n}}}})$ time per operation.

Furthermore, beginning with an empty BinaryHeap, any sequence of $m$ $\ensuremath{\mathrm{add}(\ensuremath{\mathit{x}})}$ and $\ensuremath{\mathrm{remove}()}$ operations results in a total of $O(m)$ time spent during all calls to $\ensuremath{\mathrm{resize}()}$.