Algorithm Analysis (CSC 301 2015F) : EBoards
Primary: [Front Door] [Schedule] - [Academic Honesty] [Disabilities] [Email] [FAQ] [IRC] [Teaching & Learning]
Current: [Outline] [EBoard] [Reading] [Lab] [Assignment]
Sections: [Assignments] [EBoards] [Examples] [Handouts] [Labs] [Outlines] [Readings]
Reference: [Algorist]
Related Courses: [Walker (2014F)]
Misc: [SamR] [Glimmer Labs] [CS@Grinnell] [Grinnell] [Issue Tracker]
Overview
Deletion is confusing
We'll work through some of it today.
Problem 13.3-6
The RB-INSERT and RB-INSERT-FIXUP procedures often refer to x.p or x.p.p (or something equivalent). That suggests that the underlying implementation stores a parent pointer in each node.
pmeansparent, at least in this context.Real data structures try to conserve space. Do I really need the parent pointer? Can I write fixup without it? Yes, you can do the stupid "search the whole tree for the parent". But that's not efficient. So find an efficient approach. * Note: You may need to gather information during insert to use during fixup.
Some simple cases (removing z)
|
z => NIL
/ \
NIL NIL
| |
z => r
/ \ / \
NIL r ? ?
/ \
? ?
| |
z => l
/ \ / \
l NIL ? ?
/ \
? ?
z => y
/ \ / \
l y l x
/ \
NIL x
z => z => y
/ \ / \ / \
l r l y l r
/ \ / \ / \
. ? NIL r .
. / \ .
. . ? .
y . x
/ \ .
NIL x x
|
z => NIL
/ \
NIL NIL
| |
z => RED
/ \ / \
NIL RED NIL NIL
/ \
NIL NIL
z => y
/ \ / \
l y l x
/ \
NIL x
z => z => y
/ \ / \ / \
l r l y l r
/ \ / \ / \
. ? NIL r .
. / \ .
. . ? .
y . x
/ \ .
NIL x x
The main thing to fix: We've broken the black height property by 1. We need to fix it. Identify cases and do clever rotations and recolorings.