anildas
Newbie
Rating: 0
Offline
Posts: 3
|
 |
« on: July 17, 2009, 01:26:39 PM » |
|
Sedgewick's Algorithms in Java book gives a BST join algorithm and claims the complexity is linear.
The algorithm (in pseudo code) is:
join(a, b) /* Join the trees rooted at a and b and return the root of the join */ { if (a == null) return b; if (b == null) return a;
r = root_insert(b, a); r.left = join(a.left, r.left); r.right = join(a.right, r.right); return r; }
i.e. Insert the root of a into b, using "root insert" method so that it becomes the new root of b. The left subtree of a will now have nodes that are all less than this new root. So will the new left subtree of b. Recursively join these two subtrees and set it as the new left subtree of b. Do a similar operation for the right subtree.
root_insert is done by inserting the node into the tree, and then rotating it up to the root, recursively using order preserving rotations.
insert_root(r, n) /* Insert node n into subtree tree rooted at r and return new root */ { if (r == null) return n; if (n.key < r.key) { r.left = insert_root(r.left, n); r = rotR(r); return r; } else { r.right = insert_root(r.right, n); r = rotL(r); return r; } }
I won't write out rotR and rotL. They are well known. rotR rotates the tree to the right so that the left child is the new root and so on.
Anyways, for the join algorithm, the book claims "Each node can be the root node on a recursive call at most once, so the total time is linear.". This has me confused. It is true that join will be called on each node only once, but each join call results in an insert_root call, and the insert root has cost proportional to the height of the subtree because of the insertion and the rotations. So wouldn't the overall cost of the join be proportional to the number of nodes times the height of b? And that doesn't seem to be any better than just inserting each node of a into b, one by one.
What am I missing?
|