CSE 326: Data Structures Lecture #10 Amazingly Vexing Letters Bart Niswonger Summer Quarter 2001

Today’s Outline AVL Trees Splay Trees Deletion buildTree Thinking about AVL trees Splay Trees Today we are going to wrap up Avl and attempt to delve into splay trees

Deletion (Really Easy Case) 1 2 3 Delete(17) 10 5 15 2 9 12 20 We saw this last time – it is just a basic BST delete – the heights are not disturbed, all is well 3 17 30

Deletion (Pretty Easy Case) 1 2 3 Delete(15) 10 5 15 2 9 12 20 Again – a BST deletion – find successor and replace 15 with it 3 17 30

Deletion (Pretty Easy Case cont.) 3 Delete(15) 10 2 2 5 17 1 1 2 9 12 20 Result – heights are unchanged 3 30

Deletion (Hard Case #1) Delete(12) 10 5 17 2 9 12 20 3 30 3 2 1 2 3 Delete(12) 10 5 17 2 9 12 20 Now, let’s delete 12. 12 goes away. Now, there’s trouble. We’ve put an imbalance in. So, we check up from the point of deletion and fix the imbalance at 17. 3 30

Single Rotation on Deletion 1 2 3 3 10 10 2 1 5 17 5 20 1 2 9 20 2 9 17 30 But what happened on the fix? Something very disturbing. The subtree’s height changed!! So, the deletion can propagate. 3 30 3 What is different about deletion than insertion?

Deletion (Hard Case) Delete(9) 10 5 17 2 9 12 12 20 20 3 11 15 15 18 3 4 Delete(9) 10 5 17 2 9 12 12 20 20 Now, let’s delete 9 What rotation are we going to use to fix this? 1 1 3 11 15 15 18 30 30 13 13 33 33

Double Rotation on Deletion 1 2 3 4 2 1 3 4 10 10 5 17 3 17 2 2 12 20 2 5 12 20 Why are we not finished? What is wrong? We need to fix the root – its subtrees are very different heights This is an example of the general problem with deletetions – they can propogate 1 1 1 1 3 11 15 18 30 11 15 18 30 13 33 13 33 Not finished!

Deletion with Propagation 2 1 3 4 10 What rotation do we apply? 3 17 2 5 12 20 We get to choose whether to single or double rotate! 1 1 11 15 18 30 13 33

Propagated Single Rotation 2 1 3 4 4 10 17 3 2 3 17 10 20 1 2 1 2 5 12 20 3 12 18 30 1 1 1 11 15 18 30 2 5 11 15 33 13 33 13

Propagated Double Rotation 2 1 3 4 4 10 12 2 3 3 17 10 17 1 1 2 2 5 12 20 3 11 15 20 1 1 1 11 15 18 30 2 5 13 18 30 13 33 33

AVL Deletion Algorithm Recursive If at node, delete it Otherwise recurse to find it 3. Correct heights a. If imbalance #1, single rotate b. If imbalance #2 (or don’t care), double rotate Iterative 1. Search downward for node, stacking parent nodes 2. Delete node 3. Unwind stack, correcting heights a. If imbalance #1, single rotate b. If imbalance #2 (or don’t care) double rotate OK, here’s the algorithm again. Notice that there’s very little difference between the recursive and iterative. Why do I keep a stack for the iterative version? To go bottom to top. Can’t I go top down? Now, what’s left? Single and double rotate!

Fun with AVL Trees To Insert a sequence of n keys (unordered) 19 3 4 18 7 into initially empty AVL tree takes If we then print using inorder traversal taking O(n) what do we get?

If it is sorted, why bother? What can we improve? Printing every node is O(n), nothing to do What about building a tree? Can we do it in less than O(n log n) What if the input is sorted? 3 4 7 18 19 If it is sorted, why bother? We’ll see in a moment!

AVL buildTree Divide & Conquer 5 8 10 15 17 20 30 35 40 Divide the problem into parts Solve each part recursively Merge the parts into a general solution 17 IT DEPENDS! 8 10 15 5 20 30 35 40 How long does divide & conquer take?

BuildTree Example 5 8 10 15 17 20 30 35 40 3 17 5 8 10 15 2 2 20 30 35 40 10 35 20 30 5 8 1 1 8 15 30 40 5 20

BuildTree Analysis (Approximate) T(n) = 2T(n/2) + 1 T(n) = 2(2T(n/4)+1) + 1 = 4T(n/4) + 2 + 1 T(n) = 4(2T(n/8)+1) + 2 + 1 = 8T(n/8) + 4 + 2 + 1 T(n) = 2kT(n/2k) + ½ sum i = 1 to k of 2^i let 2k = n, log n = k T(n) = nT(1) + ½ sum i = 1 to log n of 2^i T(n) = (n) Summation is 2^logn + 2^logn-1 + 2^logn-2+… 2^log n + (2^log n) * (2^-1) + (2 ^ log n) * (2^-2)…. n + n * 2^-1 + n * 2^-2… n+n/2+n/4+n/8+… ~2n

BuildTree Analysis (Exact) Precise Analysis: T(0) = b T(n) = T( ) + T( ) + c By induction on n: T(n) = (b+c)n + b Base case: T(0) = b = (b+c)0 + b Induction step: T(n) = (b+c) + b + (b+c) + b + c = (b+c)n + b QED: T(n) = (b+c)n + b = (n)

Application: Batch Deletion Suppose we are using lazy deletion When there are lots of deleted nodes (n/2), need to flush them all out Batch deletion: Print non-deleted nodes into an array How? Divide & conquer AVL Treebuild Total time: Why we cared!

Thinking About AVL Observations + Worst case height of an AVL tree is about 1.44 log n + Insert, Find, Delete in worst case O(log n) + Only one (single or double) rotation needed on insertion - O(log n) rotations needed on deletion + Compatible with lazy deletion - Height fields must be maintained (or 2-bit balance)

Alternatives to AVL Trees Change the balance criteria: Weight balanced trees keep about the same number of nodes in each subtree not nearly as nice Change the maintenance procedure: Splay trees “blind” adjusting version of AVL trees no height information maintained! insert/find always rotates node to the root! worst case time is O(n) amortized time for all operations is O(log n) mysterious, but often faster than AVL trees in practice (better low-order terms)

Splay Trees “blind” rebalancing no height or balance information stored amortized time for all operations is O(log n) worst case time is O(n) insert/find always rotates node to the root! Good locality most common keys move high in tree

Idea 10 You’re forced to make 17 a really deep access: Since you’re down there anyway, fix up a lot of deep nodes! 5 2 9 3

Splay Operations: Find Find(x) do a normal BST search to find n such that n->key = x move n to root by series of zig-zag and zig-zig rotations, followed by a final zig if necessary So, on find we just splay the sought-after node to the root.

Zig-Zag* n n Helped Unchanged Hurt g X p g p W X Y Z W Y Z This is just a double rotation. n W X Y Z W Y Z *This is just a double rotation

Zig-Zig n n g W p p Z X g Y Y Z W X Can anyone tell me how to implement this with two rotations? There are two possibilities: Start with rotate n or rotate p? Rotate p! Rotate n makes p n’s left child and then we’re hosed. Then, rotate n. This helps all the nodes in blue and hurts the ones in red. So, in some sense, it helps and hurts the same number of nodes on one rotation. Question: what if we keep rotating? What happens to this whole subtree? It gets helped! X n g Y Y Z W X

Zig n n root root p Z X p X Y Y Z In the case where we’re just one step away from the root, we single rotate. Now, each of these helped and hurt an equal number of nodes at each step, but other than this final zig, our node always helped its children, right? Therefore, every single node except p, Y, and Z in this picture improves (some quite a lot). How bad are things for p, Y, and Z? each might be down one level from where it used to be. How good are things for n and many of its descendants and former ancestors? Very good. Why not zig all the way (no zig-zig)? This just helps _one_ child of n! X Y Y Z

Why Splaying Helps Node n and its children are always helped (raised) Except for final zig, nodes that are hurt by a zig-zag or zig-zig are later helped by a rotation higher up the tree! Result: shallow (zig) nodes may increase depth by one or two helped nodes may decrease depth by a large amount If a node n on the access path is at depth d before the splay, it’s at about depth d/2 after the splay Exceptions are the root, the child of the root, and the node splayed Alright, remember what we did on Monday. We learned how to splay a node to the root of a search tree. We decided it would help because we’d go a lot of fixing up if we had an expensive access. That means we have to fix up the tree on every expensive access.

Locality Assume m  n access in a tree of size n Total amortized time O(m log n) O(log n) per access on average Gets better when you only access k distinct items in the m accesses. Exercise.

Splaying Example 1 1 2 2 zig-zig 3 3 Find(6) 4 6 5 4 5 6

Still Splaying 6 1 1 2 6 zig-zig 3 3 6 5 4 2 5 4

Almost There, Stay on Target 1 6 1 6 zig 3 3 2 5 2 5 4 4

Splay Again 6 1 6 1 zig-zag 3 4 Find(4) 2 5 3 5 4 2

Example Splayed Out 6 1 4 1 6 zig-zag 3 5 4 2 3 5 2

Splay Tree Summary All operations are in amortized O(log n) time Splaying can be done top-down; better because: only one pass no recursion or parent pointers necessary Invented by Sleator and Tarjan (1985), now widely used in place of AVL trees Splay trees are very effective search trees relatively simple no extra fields required excellent locality properties: frequently accessed keys are cheap to find All-in-all then: on the topic of locality: what happens to nodes that never get accessed? They rarely get splayed and tend to drop to the bottom of the tree (leaving the top for more valuable stuff) What happens to nodes that are often accessed? The linger near the top of the tree where they’re cheap to access!

To Do Study for midterm! Read through section 4.7 in the book Comments & Feedback Homework IV (studying) Project II – part B

Coming Up Midterm next Wednesday A Huge Search Tree Data Structure (not on the midterm)