Asymptotics for finding the successors in a Binary Tree

Click For Summary

Discussion Overview

The discussion centers on analyzing the time complexity of successive calls to the TREE-SUCCESSOR algorithm in a Binary Search Tree (BST). Participants explore the implications of the algorithm's structure and seek to prove that k successive calls take O(k+h) time, where h is the height of the tree. The conversation involves mathematical reasoning and attempts to establish bounds on the performance of the algorithm.

Discussion Character

  • Technical explanation
  • Mathematical reasoning
  • Debate/contested

Main Points Raised

  • One participant presents the TREE-SUCCESSOR and TREE-MINIMUM algorithms, claiming that k successive calls to TREE-SUCCESSOR take O(k+h) time based on the structure of the BST.
  • The same participant attempts to derive an upper bound for the number of loop runs based on the height of the tree and the sequence of calls.
  • Another participant challenges the initial approximation, suggesting that it does not accurately account for the occurrences of h, h-1, etc., in the half-tree, and proposes that a stronger bound can be derived.
  • A later reply reiterates the importance of considering the time complexity for ranges less than the total number of elements in the tree, emphasizing that O(h+k) should hold for any range.
  • One participant expresses confusion regarding the counting of occurrences in their summation and seeks clarification on how to strengthen their argument.
  • Another participant suggests a strategy to demonstrate that traversing the full tree is O(k+h) and to show that traversing more than half also adheres to this complexity, indicating a method to split sequences into manageable cases.

Areas of Agreement / Disagreement

Participants do not reach a consensus on the correctness of the initial approximation or the method for deriving the time complexity. Multiple competing views remain regarding the appropriate bounds and counting methods.

Contextual Notes

Participants express uncertainty about the assumptions made in their calculations and the implications of different ranges of k in relation to the total number of elements in the tree. There is also a lack of clarity on how to accurately count the occurrences of loop runs in the proposed summation.

mooncrater
Messages
215
Reaction score
18
Consider the algorithms :
Code:
TREE-SUCCESSOR(x)
1. if x.right_child !=NIL
2.        return TREE-MINIMUM(x.right_child)
3. y=x.parent
4. while y != NIL and x == y.right_child
5.        x = y
6.        y = y.parent
7. return y

Code:
TREE-MINIMUM(x)
1.  while x.left_child != NIL
2.         x = x.left_child
3.return x

This algorithm finds the successor of an element in a Binary Search Tree. Here, x is the pointer to the node whose successor we have to find, and TREE-MINIMUM(x) finds the minimum in a tree whose root is x. The running time of this algorithm is ##O(h)##, where h is the height of the tree.

Now the question is:

Prove that no matter what node we start at in a height-h binary search tree, k successive calls to TREE-SUCCESSOR take ##O(k+h)## time.(where h is the height of the tree.)
(clrs 12.2-8)
I've assumed that "successive calls" mean that we find the successor of the element, which came out to be the successor in the last use of TREE-SUCCESSOR.
Now, we know that in a BInary Search Tree, the left most element is the least element. Thus, starting from the leftmost element.
FullBinary.jpg

In this image, we've a tree of height 3. When we start from the left-most node, we get the following number of loop runs for successive elements:
##1,1,2,2,1,1,3,3,1,1,2,2,1,1##
thus we can group sub-parts of this sequence :
## (1,1,2,2,1,1),3,3,(1,1,2,2,1,1)##
For maximum number of total loop runs for k successive calls, we start from the ##3,3##, i.e. the ##h,h##, where h is the height of the tree.For example,
If ##k=2##
then we take the ##3,3##
If ##k=4## then we include the ##1,1## from either of the sides.
Similarly, if ##k=8## we take one of the ##2,2## from either of the sides.
Now, we assume that ##(1,1,2,2,1,1)## are whole blocks, and that the sequence is symmetric, so it's basically the two times of:
##3,1,1,2,2,1,1##
Thus generally, two times of:
##h,1,1,2,2,1,1,h-1,h-1,1,1,2,2,1,1,h-2,h-2,...##
Since, I halved the sequence, values of ##k## are also halved.
Thus an approximate value of this summation would be:
$$ 2 \times \frac {(k/2 -1)} {6} \times 8 + 2 \times (\frac { k/2} {8})( h + \frac { k/2} {8} -1 ) $$
Number of such blocks are : ## 2 \times (\frac { k/2 -1} {6}) \times 8##
as we go through the halved sequence, we used ##k/2 ## and multiplied by 2. Since there are 6 elements in each block and their sum is 8, therefore division by the former and multiplication by the former is done.
We tackle the ##h,h-1,h-1,h-2,h-2## by finding the number of such terms, i.e ## \frac { k/2 }{8}## and the summation of such terms is done using the summation of an Arithmetic progression.(Though only ##h## is used, instead of ##2\times h##.)
This summation yields an upper bound of ##O(k\times h)## instead of ##O(k+h)##.
So, where am I wrong? Any help appreciated.
 
Mathematics news on Phys.org
Your approximation is not strong enough. In your half-tree, h occurs only once, h-1 occurs only twice, and so on. You can use this to derive a stronger bound (you can also find the precise number of steps).

Note that it is not sufficient to just consider the case where k is the whole range of the tree, O(h+k) should hold for every range in it as well.
 
  • Like
Likes   Reactions: mooncrater
mfb said:
Note that it is not sufficient to just consider the case where k is the whole range of the tree, O(h+k) should hold for every range in it as well.
Well, that's what I tried to do. Instead of taking the whole range of the tree, I considered a range ##k## that is less than ##n## (the total number of elements), By starting from the elements who need ##h## loop runs, in order to find their successor. And as ##k## increases, I included other elements from the left and right. This was done to find an upper bound of the summation.

mfb said:
Your approximation is not strong enough. In your half-tree, h occurs only once, h-1 occurs only twice, and so on. You can use this to derive a stronger bound (you can also find the precise number of steps).
But, I did count them in the second summation. Should I only count them? It's not clear to me, can you please elaborate?
Thanks for replying though. :)
Moon
 
I would first show that going through the full tree is O(k+h), then showing that going through more than half of the whole tree is O(k+h), then show that you can split every other sequence into those cases plus O(k+h) steps overhead.
 
  • Like
Likes   Reactions: mooncrater

Similar threads

  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 5 ·
Replies
5
Views
2K
  • · Replies 11 ·
Replies
11
Views
2K
  • · Replies 8 ·
Replies
8
Views
3K
  • · Replies 1 ·
Replies
1
Views
3K
  • · Replies 1 ·
Replies
1
Views
2K
Replies
5
Views
3K
  • · Replies 6 ·
Replies
6
Views
1K
  • · Replies 1 ·
Replies
1
Views
1K