CSE 326: Data Structures SlSplay Trees · AVL Trees Revisited •What extra info did we maintain in each node? – The height of each node • Where were rotations performed?were
Post on 13-Mar-2020
2 Views
Preview:
Transcript
AVL Trees Revisited
• Balance condition:Left and right subtrees of every nodeLeft and right subtrees of every nodehave heights differing by at most 1
– Strong enough : Worst case depth is O(log n)– Easy to maintain : one single or double rotation
• Running time for– Find ? O(log n)– Insert ?– Delete ? O(log n)
O(log n)
( g )
– buildTree ? O(n log n)
AVL Trees Revisited
• What extra info did we maintain in each node?
– The height of each node
• Where were rotations performed?Where were rotations performed?
– At the bottom-most node where an imbalance is detected
• How did we locate this node?
– Check balance on our way up out of the recursionCheck balance on our way up out of the recursion
• Seems like a lot of work, doesn’t it?
– Any wacky ideas?
Splay Trees
• Blind adjusting version of AVL treesWh b t b l ? J t t t lik !– Why worry about balances? Just rotate like crazy!
– Don’t track anything, store anything, just do it!
• Amortized time per operations is O(log n)
• Worst case time per operation is O(n)B t t d t h l– But guaranteed to happen rarely
• Splay Trees : AVL Trees :: :Skew Heaps Leftist Heaps• Splay Trees : AVL Trees :: :Skew Heaps Leftist Heaps
Recall: Amortized Complexity
If a sequence of M operations takes O(M f(n)) time,we say the amortized runtime is O(f(n)).
• Worst case time per operation can still be large, say O(n)
• Worst case time for any sequence of M operations is O(M f(n))y q p ( ( ))
Average time per operation for any sequence is O(f(n))
Amortized complexity is worst-case guarantee oversequences of operations.
Recall: Amortized Complexity
• Is amortized guarantee any weaker than worstcase?Y i i l f
• Is amortized guarantee any stronger than averagecase?
Yes, it is only for sequences
• Is average case guarantee good enough in practice?Yes, guarantees no bad sequences
• Is amortized guarantee good enough in practice?
No, adversarial input, bad day, …
• When is amortized maybe not good enough?Yes, again, no bad sequences
If that very rare O(n) operation will kill somebody
The Splay Tree Idea
10 All the way to the root!
17If you’re forced to make a really deep access:y p
Since you’re down there anyway,fix up a lot of deep nodes!
5
p p
92
3
Do it all with AVL single rotations?Consider the ordered “list tree” at left. Now do find(1) and splay it to the root with only AVL single rotations:
6 6 6 6 6 1
5
4
5
4
5
4
5
6
1 6
4
3
4
3
4
1 4
1 5
4
5
4
2
1 2
1 3
2
3
2
3
2
3
21
Do it all with AVL single rotations?
2 3 4
find(2) find(3) find(4) find(6)
1
find(1)
g
6 6
find(5)
61
2
62
3
63
4
6
1
5
6
4
6
5
5
4
5
4
1 5
1
25
4 2
3 4
34
3
44
3 13
2
2 1
Cost of sequence: find(1), find(2), … find(n)?q ( ), ( ), ( )
Single rotations can help, but they are not enough…
Splaying node k to the root:Need to be careful!Need to be careful!
One option (that we won’t use) is to repeatedly use AVL single rotation until k becomes the root: ( S ti 4 5 1 f d t il )rotation until k becomes the root: (see Section 4.5.1 for details)
p
qF
k
s
r
D
E
q
ps
A
Ak
D
rE
FA B
B C DC
Splaying node k to the root:Need to be careful!Need to be careful!
What’s bad about this process? r is pushed almost as low as k wasBad seq: find(k) find(r) find( )Bad seq: find(k), find(r), find(…), …
q
p k
r
q
E
F
q
ps
s
Ak
Dr
q
E
FA B
B C DC
Find/Insert in Splay Trees
1. Find or insert a node k2 S l k h i h i2. Splay k to the root using three operations:
zig-zag rotationzig zig rotationzig-zig rotationplain old zig rotation
Depending on path from current location to the rootp g p
Why could this be good?? 1. Helps the new root, k
o Great if k is accessed again2 And helps many others!2. And helps many others!
o Great if many others on the path are accessed
Splay: Zig-Zag*
g k
p g pX
kkW Y WZX
Helps those in blueY Z
Just like an
Helps those in blueHurts those in red
Which nodes improve depth?Just like an…
AVL double rotation
Which nodes improve depth?
k and its original children
Splay: Zig-Zig*
kg kg
Zp
Wp
Yg
Xk
XWY Z
Is this just two AVL single rotations in a row?
Not quite – we rotate g and p, then p and k
Why does this help?Same number of nodes helped as hurt. k and its children benefit.
Special Case for Root: Zigproot k root
kZ
pX
X Y ZY
Relative depth of p, Y, Z? Relative depth of everyone else?
Down 1 level
Relative depth of p, Y, Z? Relative depth of everyone else?
Nodes under X have been repeatedly raised
Why not drop zig-zig and zig all the way? Zig only helps one child!
But Wait…
What happened here?
Didn’t two find operations take linear time instead of our promised logarithmic?
What about the amortized O(log n) guarantee?
That still holds, though we must account for the previous steps used to create this tree.
What is the worst case?
Find keys in sorted (or reverse sorted) order
Why Splaying Helps
• If a node n on the access path is at depth d before the splay it’s at about depth d/2 after the splaythe splay, it’s at about depth d/2 after the splay
• Overall, nodes which are low on the access path tend to move closer to the roottend to move closer to the root
• Splaying gets amortized O(log n) performance.
Practical Benefit of Splaying
• No heights to maintain, no imbalance to check forL t d i t d– Less storage per node, easier to code
D t d i ft d i• Data accessed once, is often soon accessed again– Splaying does implicit caching by bringing it to the root
Splay Operations: Find
• Find the node in normal BST mannerS l h d h• Splay the node to the root– if node not found, splay what would have been its parent
What if we didn’t splay?
Amortized guarantee fails!Amortized guarantee fails!Bad sequence: find(leaf k), find(k), find(k), …
Splay Operations: Insert
• Insert the node in normal BST mannerS l h d h• Splay the node to the root
What if we didn’t splay?
Amortized guarantee fails!Amortized guarantee fails!Bad sequence: insert(k), find(k), find(k), …
Splay Operations: RemoveEverything else splayed, so we’d better do that for remove
kfind(k)
L RL R
delete k
L R > k< k
Now what?
JoinJ i (L R)Join(L, R):
given two trees such that (stuff in L) < (stuff in R), merge them:
Lsplay
L R Rmax
Splay on the maximum element in L, then attach RSimilar to BST delete find max find element with no right childSimilar to BST delete – find max = find element with no right child
Does this work to join any two trees? No, need L < R
Splay Tree Summary
• All operations are in amortized O(log n) time
• Splaying can be done top-down; this may be better because:– only one pass Like what? Skew heaps! (don’t need to wait)only one pass– no recursion or parent pointers necessary– we didn’t cover top-down in class
Like what? Skew heaps! (don t need to wait)
p
• Splay trees are very effective search trees– Relatively simple– No extra fields required
E cellent l lit properties:
What happens to node that never get accessed?(tend to drop to the bottom)
– Excellent locality properties: frequently accessed keys are cheap to find
Other Possibilities?• Could use different balance conditions, different ways to
maintain balance different guarantees on running timemaintain balance, different guarantees on running time, …
• Many other balanced BST data structuresy– Red-Black trees– AA trees
Splay Trees– Splay Trees– 2-3 Trees– B-Trees– …
Red-Black Trees Not on midterm
Structure property:– Every node is “colored” either red or black.y– The root is black.– If a node is red, its children are black. (A leaf can be red.)– For each node, all paths down to null pointer must contain
the same number of black nodes.
36
Red-Black Trees Not on midterm
Notes:• Uses the standard rotations plus some coloring• Uses the standard rotations, plus some coloring
operations, to maintain structure.• Worst case find insert delete: O(log n)Worst case find, insert, delete: O(log n)• Has nice top-down, non-recursive implementation.• Java uses top-down red-black trees (TreeMap)• Java uses top-down red-black trees (TreeMap)
37
Treaps Not on midterm
Order property:h d h d l i d i i l• Each node has a randomly assigned priority value,
in addition to its key value.T h b th BST d h d !• Tree has both BST and heap order!
38Orange = low priority value, Yellow = high priority value
top related