MHB What is the Time Complexity of These Binary Search Tree Functions?

AI Thread Summary
The discussion focuses on analyzing the time complexity of two binary search tree lookup functions. The first function is recursive, and its time complexity is determined to be O(h), where h is the height of the tree, which can range from O(log n) for balanced trees to O(n-1) for unbalanced trees. A proof is sought to justify this complexity, emphasizing that the maximum path length from the root to a leaf cannot exceed the height of the tree. The second function is iterative, and while initially thought to have a complexity of O(n), it is suggested that it may also be O(h). The discussion emphasizes the importance of understanding the algorithms' behavior in both best and worst-case scenarios, and it encourages a detailed examination of the code to clarify the similarities and differences in their performance. The need for precise definitions and logical reasoning in proofs is also highlighted, particularly regarding the conditions under which the complexities apply.
evinda
Gold Member
MHB
Messages
3,741
Reaction score
0
Hello! (Wave)

The following two functions are given and I want to find their time complexity.
Code:
function BinarySearchTreeLookUp(key K,pointer R): Type
   if (R==NULL) return nill;
   else if (K==R->key) return R->data;
   else if (K<R->key)
         return(BinarySearchTreeLookUp(K,R->LC));
   else 
         return(BinarySearchTreeLookUp(K,R->RC));
Code:
function BinarySearchTreeLookUp(key K,pointer R): Type
   P=R;
   while (P!=NULL && K!=P->key){
            if (K<P->key) P=P->LC;
            else P=P->RC;
   }
   if (P!=NULL) return(P->data);
   else return nill;
}

I think that the time complexity of the first function is $O(h)$ where $\log n \leq h \leq n-1$ and that the time complexity of the second function is $O(n)$. Am I right? (Thinking)
 
Technology news on Phys.org
Hello, evinda. Let me quickly preempt all of your follow-up questions by asking you to produce a proof (or a sketch of a proof) that the time complexity of the first algorithm is $O(h)$ where $h$ is presumably the height of the input binary search tree. Then we can check and discuss your proof and hence answer not only your current question but also your real questions, which are "how could we prove it" (because you will already have a proof) and "why does it work" (because you will hopefully understand your own proof). We can discuss the second algorithm once you have finished working on the first one.

If you are somehow only interested in knowing whether your answers are correct, you are right for the first algorithm (assuming $h$ is the height of the tree, which I think is what you meant - please define any variables you use) and completely wrong for the second algorithm.

PS: "nill" is not a word. it's either "null" or "nil" (probably "null" since you are already using it).​
 
Bacterius said:
Hello, evinda. Let me quickly preempt all of your follow-up questions by asking you to produce a proof (or a sketch of a proof) that the time complexity of the first algorithm is $O(h)$ where $h$ is presumably the height of the input binary search tree. Then we can check and discuss your proof and hence answer not only your current question but also your real questions, which are "how could we prove it" (because you will already have a proof) and "why does it work" (because you will hopefully understand your own proof). We can discuss the second algorithm once you have finished working on the first one.

We have the worst case if either all the keys other than this of the root are greater than this of the root either all the other keys are smaller than this of the root, because in such cases the tree is not balanced.
Then the height of the tree will be equal to the height of the root, that is at the worst case $n-1$.
At the best case, we will have a balanced tree of which we know that the height is $O(\lg n)$.
No matter in which case we are, we cannot have a greater time complexity than $O(h)$ since the path that we will follow cannot be greater than the greatest path from the root to a leaf, that is $O(h)$.
Right? (Thinking)

Bacterius said:
If you are somehow only interested in knowing whether your answers are correct, you are right for the first algorithm (assuming $h$ is the height of the tree, which I think is what you meant - please define any variables you use) and completely wrong for the second algorithm.

Yes, with $h$ I mean the height of the tree... (Nod)

Is the time complexity of the second algorithm also $O(h)$ ? (Thinking)
 
evinda said:
We have the worst case if either all the keys other than this of the root are greater than this of the root either all the other keys are smaller than this of the root, because in such cases the tree is not balanced.

This formulation is kind of awkward. A tree has only one root. Perhaps a better way to put is "if every node's key is greater than its parent node's key or if every node's key is smaller than its parent node's key". That way you make sure that the statement holds for every node, not just the root, which identifies the worst case correctly (basically, a linked list). Otherwise your definition above would apply to trees such as these, which are clearly not the worst case:
PD0U9Y9.png

As you can see, every node other than the root has a smaller key than the root's key, yet the algorithm still performs well. You could also show a picture of an actual worst case tree for illustration if you wanted.

Also, you haven't yet given the proof that the algorithm runs in $O(h)$, so this doesn't explain why it is a worst case. This should be moved after the proof that the algorithm runs in $O(h)$.

evinda said:
At the best case, we will have a balanced tree of which we know that the height is $O(\lg n)$.

Okay, sure. You might give the exact height of a balanced tree, which is $\lceil \log_2 n \rceil$ (or something similar depending on your exact definition of "height"). That way your O-notation is justified. You could show a picture of the best case if you wanted.

Same remark as before, why is this a best case? Should be moved after the proof that the algorithm runs in $O(h)$.

evinda said:
No matter in which case we are

Wait, are you giving a proof only for the best and worst case, or does it work for all $n$? You can't just give a proof for the best and worst case and then interpolate it for every $n$ in between, it doesn't work like that. So get rid of this, replace it by "for any $n$-node binary search tree of some height $h$" and move your best/worst case remarks after this paragraph.
evinda said:
we cannot have a greater time complexity than $O(h)$ since the path that we will follow cannot be greater than the greatest path from the root to a leaf, that is $O(h)$.

Why is that? I mean, yes, okay, but you should explain why the path can't be greater longer than the greatest longest path from the root to any leaf. For instance, a convincing argument for this step (that doesn't use paths) could be "at each iteration, the algorithm either stops, or recurses down to a child of the current node, which amounts to going down one level of the tree, therefore it must reach a leaf in at most $h$ iterations, at which point it will stop". Try and come up with an argument using paths. It doesn't have to be as rigorous as a formal logic proof, but it should be enough that anyone reading it can convince himself that the argument is solid.

evinda said:
Is the time complexity of the second algorithm also $O(h)$ ? (Thinking)

Maybe. Maybe not. Try running the algorithm on the worst case and best case inputs to the previous algorithm, to see how they compare. Then, look at the code for the second algorithm. What is that while loop doing? Run through both algorithms step by step on the same input. Aren't they basically doing the same thing? What does that mean? Often just walking through each step of the algorithm is the best way to understand it, it's not just for computers!
 
Thread 'Is this public key encryption?'
I've tried to intuit public key encryption but never quite managed. But this seems to wrap it up in a bow. This seems to be a very elegant way of transmitting a message publicly that only the sender and receiver can decipher. Is this how PKE works? No, it cant be. In the above case, the requester knows the target's "secret" key - because they have his ID, and therefore knows his birthdate.
I tried a web search "the loss of programming ", and found an article saying that all aspects of writing, developing, and testing software programs will one day all be handled through artificial intelligence. One must wonder then, who is responsible. WHO is responsible for any problems, bugs, deficiencies, or whatever malfunctions which the programs make their users endure? Things may work wrong however the "wrong" happens. AI needs to fix the problems for the users. Any way to...

Similar threads

Replies
1
Views
2K
Replies
0
Views
2K
Replies
8
Views
2K
Replies
2
Views
1K
Replies
1
Views
2K
Replies
3
Views
4K
Replies
4
Views
2K
Back
Top