Red-black tree

A red-black tree is a type of self-balancing binary search tree, a data structure used in computer science, typically used to implement associative arrays. The original structure was invented in 1972 by Rudolf Bayer who called them "symmetric binary B-trees", but acquired its modern name in a paper in 1978 by Leo J. Guibas and Robert Sedgewick. It is complex, but has good worst-case running time for its operations and is efficient in practice: it can search, insert, and delete in O(log n) time, where n is the number of elements in the tree.

Terminology

A red-black tree is a special type of binary tree, used in computer science to organize pieces of comparable data, such as numbers.

In red-black trees, the leaf nodes are not relevant and do not contain data. To save memory, sometimes a single sentinel node performs the role of all leaf nodes. All references from internal nodes to leaf nodes instead point to the sentinel node.

Red-black trees, like all binary search trees, allow efficient in-order traversal of elements provided that there is a way to locate the parent of any node. The search-time results from the traversal from root to leaf, and therefore a balanced tree, having the least possible tree height, results in O(log n) search time.

Properties

An example of a red-black tree

A red-black tree is a binary search tree where each node has a color attribute, the value of which is either red or black. In addition to the ordinary requirements imposed on binary search trees, the following additional requirements of any valid red-black tree apply:

1. A node is either red or black.
2. The root is black.
3. All leaves are black, even when the parent is black (The leaves are the null children.)
4. Both children of every red node are black.
5. Every simple path from a node to a descendant leaf contains the same number of black nodes, either counting or not counting the null black nodes. (Counting or not counting the null black nodes does not affect the structure as long as the choice is used consistently.).

These constraints enforce a critical property of red-black trees: that the longest path from the root to a leaf is no more than twice as long as the shortest path from the root to a leaf in that tree. The result is that the tree is roughly balanced. Since operations such as inserting, deleting, and finding values requires worst-case time proportional to the height of the tree, this theoretical upper bound on the height allows red-black trees to be efficient in the worst-case, unlike ordinary binary search trees.

To see why these properties guarantee this, it suffices to note that no path can have two red nodes in a row, due to property 4. The shortest possible path has all black nodes, and the longest possible path alternates between red and black nodes. Since all maximal paths have the same number of black nodes, by property 5, this shows that no path is more than twice as long as any other path.

In many presentations of tree data structures, it is possible for a node to have only one child, and leaf nodes contain data. It is possible to present red-black trees in this paradigm, but it changes several of the properties and complicates the algorithms. For this reason, this article uses "null leaves", which contain no data and merely serve to indicate where the tree ends, as shown above. These nodes are often omitted in drawings, resulting in a tree which seems to contradict the above principles, but which in fact does not. A consequence of this is that all internal (non-leaf) nodes have two children, although one or more of those children may be a null leaf.

Some explain a red-black tree as a binary search tree whose edges, instead of nodes, are colored in red or black, but this does not make any difference. The color of a node in this article's terminology corresponds to the color of the edge connecting the node to its parent, except that the root node is always black (property 2) whereas the corresponding edge does not exist.

Applications and related data structures

Red-black trees offer worst-case guarantees for insertion time, deletion time, and search time. Not only does this make them valuable in time-sensitive applications such as real-time applications, but it makes them valuable building blocks in other data structures which provide worst-case guarantees; for example, many data structures used in computational geometry can be based on red-black trees.

The AVL tree is another structure supporting O(log n) search, insertion, and removal. It is more rigidly balanced than Red-Black trees, leading to slower insertion and removal but faster retrieval.

Red-black trees are also particularly valuable in functional programming, where they are one of the most common persistent data structures, used to construct associative arrays and sets which can retain previous versions after mutations. The persistent version of red-black trees requires O(log n) space for each insertion or deletion, in addition to time.

Red-black trees are an isometry of 2-3-4 trees. In other words, for every 2-3-4 tree, there is a corresponding red-black tree with data elements in the same order. The insertion and deletion operations on 2-3-4 trees are also equivalent to color-flipping and rotations in red-black trees. This makes 2-3-4 trees an important tool for understanding the logic behind red-black trees, and this is why many introductory algorithm texts introduce 2-3-4 trees just before red-black trees, even though 2-3-4 trees are not often used in practice.

In 2008, Sedgewick introduced a simpler version of red-black trees called Left-Leaning Red-Black Trees by eliminating a previously unspecified degree of freedom in the implementation. This page, however, describes the 1978 version.

Operations

Read-only operations on a red-black tree require no modification from those used for binary search trees, because every red-black tree is a special case of a simple binary search tree. However, the immediate result of an insertion or removal may violate the properties of a red-black tree. Restoring the red-black properties requires a small number (O(log n) or amortized O(1)) of color changes (which are very quick in practice) and no more than three tree rotations (two for insertion). Although insert and delete operations are complicated, their times remain O(log n).

Insertion

Insertion begins by adding the node as we would in a simple binary search tree and coloring it red. What happens next depends on the color of other nearby nodes. The term uncle node will be used to refer to the sibling of a node's parent, as in human family trees. Note that:

• Property 3 (All leaves, including nulls, are black) always holds.
• Property 4 (Both children of every red node are black) is threatened only by adding a red node, repainting a black node red, or a rotation.
• Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) is threatened only by adding a black node, repainting a red node black, or a rotation.

Note: The label N will be used to denote the node being inserted; P will denote N's parent node, G will denote N's grandparent, and U will denote N's uncle. Note that in between some cases, the roles and labels of the nodes are exchanged, but in each case, every label continues to represent the same node it represented at the beginning of the case. Any color shown in the diagram is either assumed in its case or implied by these assumptions.

Each case will be demonstrated with example C code. The uncle and grandparent nodes can be found by these functions:

<source lang="c"> struct node * grandparent(struct node *n) { if ((n != NULL) && (n->parent != NULL)) return n->parent->parent; else return NULL; }

struct node * uncle(struct node *n) { struct node *g = grandparent(n); /* * Here we blindly assume that g != NULL, i.e. we suppose a rootless tree. * However, a real tree always have an uppermost root node which we can't * go past, so an appropriate tree boundary check would be required here. */ if (n->parent == g->left) return g->right; else return g->left; } </source>

Case 1: The new node N is at the root of the tree. In this case, it is repainted black to satisfy Property 2 (The root is black). Since this adds one black node to every path at once, Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) is not violated.

<source lang="c"> void insert_case1(struct node *n) { if (n->parent == NULL) n->color = BLACK; else insert_case2(n); } </source>

Case 2: The new node's parent P is black, so Property 4 (Both children of every red node are black) is not invalidated. In this case, the tree is still valid. Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) is not threatened, because the new node N has two black leaf children, but because N is red, the paths through each of its children have the same number of black nodes as the path through the leaf it replaced, which was black, and so this property remains satisfied.

<source lang="c"> void insert_case2(struct node *n) { if (n->parent->color == BLACK) return; /* Tree is still valid */ else insert_case3(n); } </source>

Note: In the following cases it can be assumed that N has a grandparent node G, because its parent P is red, and if it were the root, it would be black. Thus, N also has an uncle node U, although it may be a leaf in cases 4 and 5.

Case 3: If both the parent P and the uncle U are red, then both nodes can be repainted black and the grandparent G becomes red (to maintain Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes)). Now, the new red node N has a black parent. Since any path through the parent or uncle must pass through the grandparent, the number of black nodes on these paths has not changed. However, the grandparent G may now violate properties 2 (The root is black) or 4 (Both children of every red node are black) (property 4 possibly being violated since G may have a red parent). To fix this, this entire procedure is recursively performed on G from case 1. Note that this is a tail-recursive call, so it could be rewritten as a loop; since this is the only loop, and any rotations occur after this loop, this proves that a constant number of rotations occur.

<source lang="c"> void insert_case3(struct node *n) { struct node *u = uncle(n), *g;

if ((u != NULL) && (u->color == RED)) { n->parent->color = BLACK; u->color = BLACK; g = grandparent(n); g->color = RED; insert_case1(g); } else { insert_case4(n);

       }

} </source>

Note: In the remaining cases, it is assumed that the parent node P is the left child of its parent. If it is the right child, left and right should be reversed throughout cases 4 and 5. The code samples take care of this.

Case 4: The parent P is red but the uncle U is black; also, the new node N is the right child of P, and P in turn is the left child of its parent G. In this case, a left rotation that switches the roles of the new node N and its parent P can be performed; then, the former parent node P is dealt with using Case 5 (relabeling N and P) because property 4 (Both children of every red node are black) is still violated. The rotation causes some paths (those in the sub-tree labelled "1") to pass through the new node where they did not before, but both these nodes are red, so Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) is not violated by the rotation.

<source lang="c"> void insert_case4(struct node *n) { struct node *g = grandparent(n);

if ((n == n->parent->right) && (n->parent == g->left)) { rotate_left(n->parent); n = n->left; } else if ((n == n->parent->left) && (n->parent == g->right)) { rotate_right(n->parent); n = n->right; } insert_case5(n); } </source>

Case 5: The parent P is red but the uncle U is black, the new node N is the left child of P, and P is the left child of its parent G. In this case, a right rotation on the parent P is performed; the result is a tree where the former parent P is now the parent of both the new node N and the former grandparent G. G is known to be black, since its former child P could not have been red otherwise. Then, the colors of P and G are switched, and the resulting tree satisfies Property 4 (Both children of every red node are black). Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) also remains satisfied, since all paths that went through any of these three nodes went through G before, and now they all go through P. In each case, this is the only black node of the three.

<source lang="c"> void insert_case5(struct node *n) { struct node *g = grandparent(n);

n->parent->color = BLACK; g->color = RED; if ((n == n->parent->left) && (n->parent == g->left)) { rotate_right(g); } else { /* * Here, (n == n->parent->right) && (n->parent == g->right). */ rotate_left(g); } } </source> Note that inserting is actually in-place, since all the calls above use tail recursion.

Removal

In a normal binary search tree, when deleting a node with two non-leaf children, we find either the maximum element in its left subtree or the minimum element in its right subtree, and move its value into the node being deleted (as shown here). We then delete the node we copied the value from, which must have less than two non-leaf children. Because merely copying a value does not violate any red-black properties, this reduces the problem of deleting to the problem of deleting a node with at most one non-leaf child. It does not matter whether this node is the node we originally wanted to delete or the node we copied the value from.

For the remainder of this discussion we can assume we are deleting a node with at most one non-leaf child, which we will call its child (if it has only leaf children, let one of them be its child). If we are deleting a red node, we can simply replace it with its child, which must be black. All paths through the deleted node will simply pass through one less red node, and both the deleted node's parent and child must be black, so properties 3 (All leaves, including nulls, are black) and 4 (Both children of every red node are black) still hold. Another simple case is when the deleted node is black and its child is red. Simply removing a black node could break Properties 4 (Both children of every red node are black) and 5 (All paths from any given node to its leaf nodes contain the same number of black nodes), but if we repaint its child black, both of these properties are preserved.

The complex case is when both the node to be deleted and its child is black. We begin by replacing the node to be deleted with its child. We will call (or label) this child (in its new position) N, and its sibling (its new parent's other child) S. In the diagrams below, we will also use P for N's new parent, S_L for S's left child, and S_R for S's right child (it can be shown that S cannot be a leaf).

Note: In between some cases, we exchange the roles and labels of the nodes, but in each case, every label continues to represent the same node it represented at the beginning of the case. Any color shown in the diagram is either assumed in its case or implied by these assumptions. White represents an unknown color (either red or black).

We will find the sibling using this function:

<source lang="c"> struct node * sibling(struct node *n) { if (n == n->parent->left) return n->parent->right; else return n->parent->left; } </source>

Note: In order that the tree remains well-defined, we need that every null leaf remains a leaf after all transformations (that it will not have any children). If the node we are deleting has a non-leaf (non-null) child N, it is easy to see that the property is satisfied. If, on the other hand, N would be a null leaf, it can be verified from the diagrams (or code) for all the cases that the property is satisfied as well.

We can perform the steps outlined above with the following code, where the function replace_node substitutes child into n's place in the tree. For convenience, code in this section will assume that null leaves are represented by actual node objects rather than NULL (the code in the Insertion section works with either representation).

<source lang="c"> void delete_one_child(struct node *n) { /* * Precondition: n has at most one non-null child. */ struct node *child = is_leaf(n->right) ? n->left : n->right;

replace_node(n, child); if (n->color == BLACK) { if (child->color == RED) child->color = BLACK; else delete_case1(child); } free(n); } </source>

Note: If N is a null leaf and we do not want to represent null leaves as actual node objects, we can modify the algorithm by first calling delete_case1() on its parent (the node that we delete, n in the code above) and deleting it afterwards. We can do this because the parent is black, so it behaves in the same way as a null leaf (and is sometimes called a 'phantom' leaf). And we can safely delete it at the end as n will remain a leaf after all operations, as shown above.

If both N and its original parent are black, then deleting this original parent causes paths which proceed through N to have one fewer black node than paths that do not. As this violates Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes), the tree must be rebalanced. There are several cases to consider:

Case 1: N is the new root. In this case, we are done. We removed one black node from every path, and the new root is black, so the properties are preserved.

<source lang="c"> void delete_case1(struct node *n) { if (n->parent != NULL) delete_case2(n); } </source>

Note: In cases 2, 5, and 6, we assume N is the left child of its parent P. If it is the right child, left and right should be reversed throughout these three cases. Again, the code examples take both cases into account.

Case 2: S is red. In this case we reverse the colors of P and S, and then rotate left at P, turning S into N's grandparent. Note that P has to be black as it had a red child. Although all paths still have the same number of black nodes, now N has a black sibling and a red parent, so we can proceed to step 4, 5, or 6. (Its new sibling is black because it was once the child of the red S.) In later cases, we will relabel N's new sibling as S.

<source lang="c"> void delete_case2(struct node *n) { struct node *s = sibling(n);

if (s->color == RED) { n->parent->color = RED; s->color = BLACK; if (n == n->parent->left) rotate_left(n->parent); else rotate_right(n->parent); } delete_case3(n); } </source>

Case 3: P, S, and S's children are black. In this case, we simply repaint S red. The result is that all paths passing through S, which are precisely those paths not passing through N, have one less black node. Because deleting N's original parent made all paths passing through N have one less black node, this evens things up. However, all paths through P now have one fewer black node than paths that do not pass through P, so Property 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) is still violated. To correct this, we perform the rebalancing procedure on P, starting at case 1.

<source lang="c"> void delete_case3(struct node *n) { struct node *s = sibling(n);

if ((n->parent->color == BLACK) && (s->color == BLACK) && (s->left->color == BLACK) && (s->right->color == BLACK)) { s->color = RED; delete_case1(n->parent); } else delete_case4(n); } </source>

Case 4: S and S's children are black, but P is red. In this case, we simply exchange the colors of S and P. This does not affect the number of black nodes on paths going through S, but it does add one to the number of black nodes on paths going through N, making up for the deleted black node on those paths.

<source lang="c"> void delete_case4(struct node *n) { struct node *s = sibling(n);

if ((n->parent->color == RED) && (s->color == BLACK) && (s->left->color == BLACK) && (s->right->color == BLACK)) { s->color = RED; n->parent->color = BLACK; } else delete_case5(n); } </source>

Case 5: S is black, S's left child is red, S's right child is black, and N is the left child of its parent. In this case we rotate right at S, so that S's left child becomes S's parent and N's new sibling. We then exchange the colors of S and its new parent. All paths still have the same number of black nodes, but now N has a black sibling whose right child is red, so we fall into case 6. Neither N nor its parent are affected by this transformation. (Again, for case 6, we relabel N's new sibling as S.)

<source lang="c"> void delete_case5(struct node *n) { struct node *s = sibling(n);

if ((n == n->parent->left) && (s->color == BLACK) && (s->left->color == RED) && (s->right->color == BLACK)) { s->color = RED; s->left->color = BLACK; rotate_right(s); } else if ((n == n->parent->right) && (s->color == BLACK) && (s->right->color == RED) && (s->left->color == BLACK)) { s->color = RED; s->right->color = BLACK; rotate_left(s); } delete_case6(n); } </source>

Case 6: S is black, S's right child is red, and N is the left child of its parent P. In this case we rotate left at P, so that S becomes the parent of P and S's right child. We then exchange the colors of P and S, and make S's right child black. The subtree still has the same color at its root, so Properties 4 (Both children of every red node are black) and 5 (All paths from any given node to its leaf nodes contain the same number of black nodes) are not violated. However, N now has one additional black ancestor: either P has become black, or it was black and S was added as a black grandparent. Thus, the paths passing through N pass through one additional black node. Meanwhile, if a path does not go through N, then there are two possibilities: It goes through N's new sibling. Then, it must go through S and P, both formerly and currently, and they have only exchanged colors. Thus the path contains the same number of black nodes. It goes through N's new uncle, S's right child. Then, it formerly went through S, S's parent, and S's right child, but now only goes through S, which has assumed the color of its former parent, and S's right child, which has changed from red to black. The net effect is that this path goes through the same number of black nodes. Either way, the number of black nodes on these paths does not change. Thus, we have restored Properties 4 (Both children of every red node are black) and 5 (All paths from any given node to its leaf nodes contain the same number of black nodes). The white node in the diagram can be either red or black, but must refer to the same color both before and after the transformation.

<source lang="c"> void delete_case6(struct node *n) { struct node *s = sibling(n);

s->color = n->parent->color; n->parent->color = BLACK; if (n == n->parent->left) { /* * Here, s->right->color == RED. */ s->right->color = BLACK; rotate_left(n->parent); } else { /* * Here, s->left->color == RED. */ s->left->color = BLACK; rotate_right(n->parent); } } </source>

Again, the function calls all use tail recursion, so the algorithm is in-place. Additionally, no recursive calls will be made after a rotation, so a constant number of rotations (up to 3) are made.

Proof of asymptotic bounds

A red black tree which contains n internal nodes has a height of O(log(n)).

Definitions:

• h(v) = height of subtree rooted at node v
• bh(v) = the number of black nodes (not counting v if it is black) from v to any leaf in the subtree (called the black-height).

Lemma: A subtree rooted at node v has at least Failed to parse (Missing texvc executable; please see math/README to configure.): 2^{bh(v)}-1

internal nodes.

Proof of Lemma (by induction height):

Basis: h(v) = 0

If v has a height of zero then it must be null, therefore bh(v) = 0. So:

Failed to parse (Missing texvc executable; please see math/README to configure.): 2^{bh(v)}-1 = 2^{0}-1 = 1-1 = 0

Inductive Step: v such that h(v) = k, has Failed to parse (Missing texvc executable; please see math/README to configure.): 2^{bh(v)}-1

internal nodes implies that Failed to parse (Missing texvc executable; please see math/README to configure.): v'
such that h(Failed to parse (Missing texvc executable; please see math/README to configure.): v'

) = k+1 has Failed to parse (Missing texvc executable; please see math/README to configure.): 2^{bh(v')}-1

internal nodes.

Since Failed to parse (Missing texvc executable; please see math/README to configure.): v'

has h(Failed to parse (Missing texvc executable; please see math/README to configure.): v'

) > 0 it is an internal node. As such it has two children which have a black-height of either bh(Failed to parse (Missing texvc executable; please see math/README to configure.): v' ) or bh(Failed to parse (Missing texvc executable; please see math/README to configure.): v' )-1 (depending on whether Failed to parse (Missing texvc executable; please see math/README to configure.): v'

is red or black).  By the inductive hypothesis each child has at least  Failed to parse (Missing texvc executable; please see math/README to configure.): 2^{bh(v')-1}-1
internal nodes, so Failed to parse (Missing texvc executable; please see math/README to configure.): v'
has:

Failed to parse (Missing texvc executable; please see math/README to configure.): 2^{bh(v')-1}-1 + 2^{bh(v')-1}-1 + 1 = 2^{bh(v')}-1

internal nodes.

Using this lemma we can now show that the height of the tree is logarithmic. Since at least half of the nodes on any path from the root to a leaf are black (property 4 of a red black tree), the black-height of the root is at least h(root)/2. By the lemma we get:

Failed to parse (Missing texvc executable; please see math/README to configure.): n \geq 2^{{h(\text{root}) \over 2}} - 1 \leftrightarrow \; \log_2{(n+1)} \geq {h(\text{root}) \over 2} \leftrightarrow \; h(\text{root}) \leq 2\log_2{(n+1)}.

Therefore the height of the root is O(log(n)).

Complexity

In the tree code there is only one loop where the node of the root of the red-black property that we wish to restore, x, can be moved up the tree by one level at each iteration.

Since the original height of the tree is O(log n), there are O(log n) iterations. So overall the insert routine has O(log n) complexity.

References

• Mathworld: Red-Black Tree
• San Diego State University: CS 660: Red-Black tree notes, by Roger Whitney
• Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein. Introduction to Algorithms, Second Edition. MIT Press and McGraw-Hill, 2001. ISBN 0-262-03293-7 . Chapter 13: Red-Black Trees, pp.273–301.
• Pfaff, Ben (June 2004). Performance Analysis of BSTs in System Software (PDF). Stanford University.
• Okasaki, Chris. Red-Black Trees in a Functional Setting (PS).

External links

Demos

• Red Black Tree Applet, a demo of red-black and many more search trees by Kubo Kovac
• Red Black Tree Applet, a demo of red-black trees, avl, rotation and many more.
• Red/Black Tree Demonstration, an interactive demo of insertion and removal with Java source code
• Red-Black Tree Animation, a demo of worst-case insertion
• aiSee: Visualization of a Sorting Algorithm, an animated GIF showing insertion (200KB)
• Red-Black Tree Demonstration, a demo of insertion with Java source code by David M. Howard
• AVL Tree Applet, an interactive demo of insertion to and removal from AVL, splay and red-black trees

Implementations

• In the C++ Standard Template Library, the containers std::set<Value> and std::map<Key,Value> are often based on red-black trees
• Efficient implementation of Red-Black Trees
• RBT: A SmallEiffel Red-Black Tree Library
• libredblack: A C Red-Black Tree Library
• Red-Black Tree C Code
• Red-Black Tree Java implementation in java.util.TreeMap
• DragonFlyBSD VM subsystems utilize Red-Black trees
• NATURAL/ADABAS implementation by Paul Macgowan
• NGenerics : implementation in C#
• FreeBSD's single header file implementation
• The default scheduler of Linux 2.6.23, called Completely Fair Scheduler, is implemented via a Red-Black treecs:Červeno-černý strom

de:Rot-Schwarz-Baum es:Árbol rojo-negro fa:درخت قرمز- سیاه fr:Arbre bicolore ko:레드-블랙 트리 hr:Crveno-crno stablo id:Pohon merah-hitam it:Albero rosso-nero he:עץ אדום שחור lt:Raudonai-Juodas medis ja:赤黒木 pl:Drzewo czerwono-czarne pt:Árvore rubro-negra ru:Красно-чёрное дерево sr:Црвено-црно стабло fi:Punamusta puu sv:Röd-svart träd vi:Cây đỏ đen uk:Червоно-чорне дерево