2

I wrote a recursive function for finding the min value of a binary tree (assume that it is not ordered).

The code is as below.

//assume node values are positive int.
int minValue (Node n) {
if(n == null) return 0;
leftmin = minValue(n.left);
rightmin = minValue(n.right);
return min(n.data, leftmin, rightmin);
}

int min (int a, int b, int c) {
int min = 0;
if(b != 0 && c != 0) {
if(a<=b) min =a;
else min =b;
if(min<=c) return min;
else return c;
}
if(b==0) {
if(a<=c) return a;
else return c;
}
if(c==0) {
if(a<=b) return a;
else return b;
}
}

I guess the time complexity of the minValue function is O(n) by intuition.

Is this correct? Can someone show the formal proof of the time complexity of minValue function?

Jane Foster
  • 441
  • 2
  • 6
  • 14
  • 1
    Is not your binary tree already ordered? Isn't finding the minimum value just plunging down the left-most branch? – Ken Thomases Mar 19 '15 at 23:51
  • 2
    Is this a binary *search* tree, or just an arbitrary binary tree? And are there any balancing guarantees? – user2357112 Mar 19 '15 at 23:54
  • 1
    Also, your `min` function is absurdly overcomplicated. There's no reason to do anything special when any of the values are zero. – user2357112 Mar 19 '15 at 23:56

3 Answers3

5

Assuming your binary tree is not ordered, then your search algorithm will have O(N) running time, so your intuition is correct. The reason it will take O(N) is that you will, on average, have to search half the nodes in the tree to find an input. But this assumes that the tree is completely unordered.

For a sorted and balanced binary tree, searching will take O(logN). The reason for this is that the search will only ever have to traverse one single path down the tree. A balanced tree with N nodes will have a height of log(N), and this explains the complexity for searching. Consider the following tree for example:

      5
    /   \
  3      7
 / \    / \
1   4  6   8

There are 8 (actually 7) nodes in the tree, but the height is only log(8) = 2. You can convince yourself that you will only ever have to traverse this tree once to find a value or fail doing so.

Note that for a binary tree which is not balanced these complexities may not apply.

Tim Biegeleisen
  • 502,043
  • 27
  • 286
  • 360
  • Searching for min/max of sorted tree should be `O(1)` both? If the BST stores a reference to head/tail - see my question https://stackoverflow.com/questions/74905603/is-finding-the-min-max-of-bst-considered-to-be-o1-time – Alexander Mills Dec 24 '22 at 04:46
  • 1
    This is not how a plain N-ary tree works, AFAIK. Of course, we can store pointers to the min and max, but then they would have to be updated/maintained with every change to the tree, which would require an `O(logN)` operation. – Tim Biegeleisen Dec 24 '22 at 04:53
  • Yes agreed, rebalancing is required frequently, but I guess rebalancing (left/right rotation) is considered O(1) and so therefore keeping a ref to min/max before or after rebalancing is O(1), the only question is if finding the next min given current min, or the next max given current max is O(1)...it seems like its bounded by at most 3 operations for any sized tree. – Alexander Mills Dec 24 '22 at 04:59
  • You should initiate this dialog under your new question rather than under my answer. – Tim Biegeleisen Dec 24 '22 at 05:02
  • Not sure I agree with that comment, I guess the best thing to do is add a new answer which hopefully you will recognize and upvote - it's a little complicated since rebalancing in both BST and Min Heap is ~O(log(N)) so when comparing apples to apples, ...hopefully you get it... https://stackoverflow.com/a/74906003/1223975 – Alexander Mills Dec 24 '22 at 06:45
2

The number of comparisons is n-1. The proof is an old chestnut, usually applied to the problem of saying how many matches are needed in a single-elimination tennis match. Each comparison removes exactly one number from consideration and so if there's initially n numbers in the tree, you need n-1 comparisons to reduce that to 1.

Paul Hankin
  • 54,811
  • 11
  • 92
  • 118
-1

You can lookup and remove the min/max of a BST in constant time O(1), if you implement it yourself and store a reference to head/tail. Most implementations don't do that, only storing the root-node. But if you analyze how a BST works, given a ref to min/max (or aliased as head/tail), then you can find the next min/max in constant time.

See this for more info: https://stackoverflow.com/a/74905762/1223975

Alexander Mills
  • 90,741
  • 139
  • 482
  • 817