Ok, so let's start by identifying what the worst case for this algorithm would be. covers
searches the tree from left to right, so you get the worst-case behavior if the node you are searching for is the rightmost leaf, or it is not in the subtree at all. At this point you will have visited all the nodes in the subtree, so covers
is O(n), where n is the number of nodes in the tree.
Similarly, commonAncestor
exhibits worst-case behavior when the first common ancestor of p
and q
is deep down to the right in the tree. In this case, it will first call covers
twice, getting the worst time behavior in both cases. It will then call itself again on the right subtree, which in the case of a balanced tree is of size n/2
.
Assuming the tree is balanced, we can describe the run time by the recurrence relation T(n) = T(n/2) + O(n)
. Using the master theorem, we get the answer T(n) = O(n)
for a balanced tree.
Now, if the tree is not balanced, we might in the worst case only reduce the size of the subtree by 1 for each recursive call, yielding the recurrence T(n) = T(n-1) + O(n)
. The solution to this recurrence is T(n) = O(n^2)
.
You can do better than this, though.
For example, instead of simply determining which subtree contains p
or q
with cover
, let's determine the entire path to p
and q
. This takes O(n)
just like cover
, we're just keeping more information. Now, traverse those paths in parallell and stop where they diverge. This is always O(n)
.
If you have pointers from each node to their parent you can even improve on this by generating the paths "bottom-up", giving you O(log n)
for a balanced tree.
Note that this is a space-time tradeoff, as while your code takes O(1)
space, this algorithm takes O(log n)
space for a balanced tree, and O(n)
space in general.
p
andq
. This takesO(n)
just likecover
... Shouldn't the path from root to nodep
takeO(log n)
instead ofO(n)
? – Incendiary