Which adds substantial overhead and does not reduce

which adds substantial overhead and does not reduce the number of cases to be handled.
The code on the next page is a full implementation of
delete()
for LLRB 2-3 trees. It is based
on the reverse of the approach used for insert in top-down 2-3-4 trees: we perform rotations and
color flips on the way down the search path to ensure that the search does not end on a 2-node, so
that we can just delete the node at the bottom. We use the method
fixUp()
to share the code for the
color flip and rotations following the
recursive calls in the
insert()
code.
With
fixUp()
, we can leave right-
leaning red links and unbalanced
4-nodes along the search path, secure
that these conditions will be fixed on
the way up the tree. (The approach is
also effective 2-3-4 trees, but requires
an extra rotation when the right node
off the search path is a 4-node.)
As a warmup, consider the de-
lete-the-minimum operation, where
the goal is to delete the bottom node
on the left spine while maintaining
balance. To do so, we maintain the in-
variant that the current node or its left
child is red. We can do so by moving
to the left unless the current node is
red and its left child and left grandchild are both black. In that case, we can do a color flip, which
restores the invariant but may introduce successive reds on the right. In that case, we can correct
the condition with two rotations and a color flip. These operations are implemented in the
mov-
eRedLeft()
method on the next page. With
moveRedLeft()
, the recursive implementation of
dele-
teMin()
above is straightforward.
For general deletion, we also need
moveRedRight()
, which is similar, but simpler, and we need
to rotate left-leaning red links to the right on the search path to maintain the invariant. If the node
to be deleted is an internal node, we replace its key and value fields with those in the minimum
node in its right subtree and then delete the minimum in the right subtree (or we could rearrange
pointers to use the node instead of copying fields). The full implementation of
delete()
that der-
vies from this discussion is given on the facing page. It uses one-third to one-quarter the amount
of code found in typical implementations. It has been demonstrated before [2, 11, 13] that main-
taining a field in each node containing its height can lead to code for delete that is similarly concise,
but that extra space is a high price to pay in a practical implementation. With LLRB trees, we can
arrange for concise code having a logarithmic performance guarantee and using no extra space.
public void deleteMin()
{
root = deleteMin(root);
root.color = BLACK;
}
private Node deleteMin(Node h)
{
if (h.left == null) return null;
if (!isRed(h.left) && !isRed(h.left.left))
h = moveRedLeft(h);
h.left = deleteMin(h.left);
return fixUp(h);
}
Delete-the-minimum code for LLRB 2-3 trees

private Node moveRedLeft(Node h)
{
colorFlip(h);
if (isRed(h.right.left))
{
h.right = rotateRight(h.right);
h = rotateLeft(h);
colorFlip(h);
}
return h;
}
private Node moveRedRight(Node h)
{
colorFlip(h);
if (isRed(h.left.left))
{
h = rotateRight(h);
colorFlip(h);
}
return h;
}
public void delete(Key key)
{
root = delete(root, key);
root.color = BLACK;
}
private Node delete(Node h, Key key)
{
if (key.compareTo(h.key) < 0)
{