1. Keeping Binary Trees Sorted

2. Search trees Searching a binary tree is easy; it’s just a preorder traversal public BinaryTree findNode(BinaryTree node, Object goal) { // try this node if (node == null) return null; // not found yet if (goal.equals(node.value)) return node; // found // look in the left subtree BinaryTree result = findNode(node.leftChild, goal); if (result != null) return result; // look in the right subtree else return findNode(node.rightChild, goal); }

3. Balance If a search tree is balanced, search time is O(log n) –Using the number of nodes in the tree as n If a search tree is unbalanced, search time could be as much as O(n) If a search tree is constructed once and searched many times, then constructing the balanced tree need not be particularly fast If insertions and deletions to the tree are frequent, then we need a fast way of rebalancing the tree Rebalancing can be done via a series of rotations

4. Rotations Notice that rotations keep the binary tree sorted! 60 50 40 20 1030 70 Rotate right about this node 60 50 40 20 1030 70 60 50 40 20 1030 70 Rotate right about this node Rotate left about this node 50 60 40 20 1030 70

5. 60 50 40 20 1030 70 60 50 40 20 1030 70 Complications When we did a rotate right, the left child ( 50 ) of the topmost node ( 60 ) did not have a left child to worry about Thus the previous topmost node ( 60 ) could become the right child of the previous left child ( 50 ) If 50 had had a right child, we would have had to do something about it

6. Rotate right with crossover When a node with an “inside” (towards the center) child moves up, the inside child must cross over Notice that this is always possible, because the previous topmost node ( 60 ) “loses” its left child 60 50 40 20 1030 70 55 60 50 40 20 1030 70 55

7. Rotate left with crossover The same thing happens if the rotation is to the left rather than to the right Notice how, in each case, the “inside” child of the node moves to be a child of the previous top node ( 50 ) and changes sides (in this case, from left child to right child) 60 50 40 20 1030 7055 50 60 40 20 1030 70 55

8. Red-black and AVL trees Rotations can be used to balance any binary tree The hard part is figuring out which rotations to perform, in what order Algorithms for doing this are complex –The two most common algorithms use binary trees with extra information: AVL trees and red-black trees With either kind of tree, the idea is to keep the tree in balance at all times –Rebalance after each insertion –Rebalance after each deletion We will not go into complete detail on either of these algorithms

9. AVL trees AVL trees are the simpler of the two kinds Each node contains (in addition to its usual fields) a field containing the difference between the depths of its two subtrees –This difference cannot be greater than 1 Nodes are added in the usual way –When a node is added, the depth may change, and a rotation (or two rotations) may be needed –When a rotation is performed, the next higher node must also be checked –This process continues, potentially all the way up to the root of the binary tree

10. Red-black trees A second way of keeping a binary tree balanced is to keep a “color” indicator in each node The “color” of a node is just a bookkeeping device There are rules that put restrictions on the color that each node can be When a tree is red-black correct (follows the rules), then it is also balanced

11. The four rules If these four conditions are met, the binary tree is balanced: 1.Every node is either “red” or “black” 2.The root is always black 3.The children of a red node must be black 4.Every path from the root to a leaf, or to a “null child,” must contain the same number of black nodes. OKNot OKOK

12. Additional operations In addition to rotations, there are additional operations that just operate on the colors –These are part of the “bookkeeping” for red-black trees The first operation is trivial: Change the color of a node The second operation is a flip: Change the color of a node and its two children There are two cases: or and Special case: If the root is the topmost node, it stays black

13. About red-black trees The notion of “red” and “black” nodes is just a bookkeeping device to tell us what rotations to perform We start with a balanced red-black tree that follows all the rules –One (root) node, black, satisfies the rules As we insert each node, we do rotations and color changes to preserve the red-black rules –In the process, the tree stays balanced –The operations are fairly complex –You do not need to memorize all the transformations, just try to get the general idea

14. Finding the insertion point We insert a value into a (sorted) red-black tree in the usual way: –If the value we are inserting is smaller than the node, go left –If the value is larger than or equal to the node, go right Along the way, if we find a black node with two red children, we flip (change the color of all three nodes) It is OK for a black node to have red children –We started with a red-black balanced tree This change does not affect the number of black nodes along any path to a leaf The change may give us two red nodes in a row (not OK) OKMaybe OK

15. Inside and outside grandchildren A grandchild (child of a child) is an inside grandchild if it is: –The left child of a right child, or –The right child of a left child A grandchild is an outside grandchild if it is: –The left child of a left child, or –The right child of a right child We use this distinction in the red-black algorithm inside grandchildren outside grandchildren

16. Cases Starting with a red-black correct tree, inserting a node, and possibly doing B-R-R  R-B-B flips along the way, there are only two kinds of problems that might arise: –Grandparent and parent are both red, and the child is an outside child –Grandparent and parent are both red, and the child is an inside child In addition, these problems may occur on the way down the tree, or after the insertion Every case requires a different sequence of operations We will not go into these details

17. In real life... Tree balancing algorithms are complex, and I do not expect you to learn them You will probably never need to implement them anyway But if you do... –Get one of the big fat algorithms books (Sedgewick is the classic) –Look up the algorithm you need –Implement it very, very carefully and test it thoroughly

18. The End