Searching a binary search tree

Searching a binary search tree is not dissimilar to the process performed when inserting an item: Compare the item that you are looking for with the root, and then `push' the comparison down into the left or right subtree depending on the result of this comparison, until a match is found or a leaf is reached. This takes at most as many comparisons as the height of the tree. At worst, this will be the number of nodes in the tree minus one, as we have seen.

But how many comparisons are required on average? In order to answer this question, we need the average height of a binary tree. This is calculated by taking all binary trees of a given size $n$ and calculating their height, which is by no means easy. The trouble is that there are many ways of building the same binary search tree by successive insertions. As we have seen above, perfectly balanced trees achieve minimal height for a given number of nodes, and it turns out that the more balanced a tree, the more ways there are of building it.

This is demonstrated in the figure below: The only way of getting the tree on the left hand side is by inserting $3$, $2$, $1$ into the empty tree in that order. The tree on the right, however, can be reached in two ways: Inserting in the order $2$, $1$, $3$ or in the order $2$, $3$, $1$.

Ideally, of course, one would only use well-balanced trees (they don't have to be perfectly balanced to perform better than binary search trees without restrictions) to keep the height minimal.

We won't do the actual calculations here (see [Aho, Hopcroft, Ullman, Data Structures and Algorithms, 1983], for more details). If we assume that all the possible orders in which the nodes might be inserted are equally likely then the average number of comparisons needed is $\log n$, since the average height of a binary search tree falls into that class. Inserting a node into a binary search tree also requires $\log n$ steps.