4

If, after insertion of a new element, the root of an RB tree becomes red, its color is changed to black. Why is that? It appears to me that red roots would work just as fine. Is this color change simply done so that subsequent operations can be done more efficiently, or is there more to it?

fredoverflow
  • 256,549
  • 94
  • 388
  • 662
  • [According to Wikipedia](http://en.wikipedia.org/wiki/Red%E2%80%93black_tree#Properties): "This rule is sometimes omitted. Since the root can always be changed from red to black, but not necessarily vice versa, this rule has little effect on analysis." – Fizz Feb 01 '15 at 20:42
  • By the way, a RB tree which doesn't have a black root is called a "relaxed red-black tree" in CLR and a few other places. – Fizz Feb 01 '15 at 20:52
  • The same terminology is sometimes used to "relax" other parts of the RB-tree definition though. – Fizz Feb 01 '15 at 21:04
  • If you want more convincing sources than Wikipedia that omit it from the "standard" definition: http://www.math.tau.ac.il/~michas/sarnak-tarjan.pdf, http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.25.6504, https://books.google.com/books?id=fuB8dMhKBzsC&pg=PA94 – Fizz Feb 01 '15 at 21:40
  • 2
    What's most interesting is that in the [original Symmetric Binary B-Trees paper](http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1457&context=cstech) which where later renamed to red-black, the root has no color assignable to it. There are two types of edges in SBBs, horizontal and vertical. The node colors that were later introduced correspond to what's at the end of each SBB edge type; a horizontal edge points to a red node, while a vertical edge points to black node. The root has no edge (of any kind) pointing to it, so no color. – Fizz Feb 01 '15 at 22:03
  • Also, there can be red leaves in a SBB. These also don't affect the balance except by a constant term, because there's at most one (extra) red leaf on every path from the root to a leaf in a SBB. – Fizz Feb 01 '15 at 22:05
  • @RespawnedFluff I would be happy to upvote your answer if you wrote one ;) – fredoverflow Feb 02 '15 at 06:31
  • I don't think I've actually answered your question, i.e. what's the practical reason it is forced black. And right now I don't have much clue how to answer it: it could be for pedagogical reasons or for code case simplification(s), but I haven't though enough about it. I've only confirmed your hypothesis, i.e. that's asymptotically fine to have it red (or no color). – Fizz Feb 02 '15 at 06:49
  • Can you guys take a look at my Red Black Tree remove method? http://stackoverflow.com/questions/28705454/how-to-fix-remove-in-redblacktree-implementation – committedandroider Feb 25 '15 at 19:08
  • 1
    This all looks like a chat room conversation, not a SO question. – Lightness Races in Orbit Apr 24 '15 at 18:20

2 Answers2

1

Strictly speaking, there is no technical reason why the root has to be black. The tree will still be balanced (having height O(log n)) even if the root can be red, and the color rules can be fixed up after an insertion or deletion without changing their O(log n) runtimes.

There are two main reasons why we would make the root black, though.

The first is that red/black trees are an isometry of 2-3-4 trees. A 2-3-4 tree is a type of multi-way search tree in which each node can have 1, 2, or 3 keys in it. You can convert any red/black tree into a 2-3-4 tree by “pulling” all red nodes up into their black parents. (This is how red/black trees were first invented, by the way!) In that sense, each black node in a red/black tree corresponds to a node in the 2-3-4 tree, and each red node corresponds to an extra key placed into that node.

The second is a corollary of the first - the rules for maintaining all the red/black tree requirements after an insertion or deletion are all derived by looking at the corresponding rules for maintaining a 2-3-4 tree after an insertion or deletion. By enforcing the rule that the root node is black, it’s a lot easier to translate the 2-3-4 tree algorithms to red/black trees. Specifically, the rules for 2-3-4 trees work by looking at nodes and their parents, which correspond in red/black trees to looking at black nodes and their nearest black ancestor in the red/black tree. Therefore, by ensuring the root node is black, we simplify the fixup algorithms by ensuring that whenever we need to look for a red/black tree node’s nearest black ancestor, one always exists.

templatetypedef
  • 362,284
  • 104
  • 897
  • 1,065
0

One possible explanation comes from the height of the tree. The height is in Theta(log n).

It is more than clear that is at least in Omega(log n), since RB-Trees are BTs. Then comes O(log n) into play.

Since a red node can have no red parent, the height is no more than two times the maximal black depth(BD) of one external node (all external nodes have the same BD). Therefore <= log n (in floor).

Imagine now a tree with only one node - the root. If it's black, then we have 1 BD of all external nodes => less or equal than 2 height, which is alright.

But if the root was red, then the depth of the external nodes must be less than 2 * 0, actually in reality it is 1. A contradiction, since 1 < 0.

That's why you can't always change the root from black to red. Reversely, you can always add up to the black height, for example after a rotation at deletion or insertion.

Dimitar
  • 4,402
  • 4
  • 31
  • 47