I am trying to understand how red black trees work, assume the transition from first to the second at the picture, I get it this without any problem, after this according to teaching resources, I need to do a local fix on the red G node.
So as a fix to the 2nd step, does G simply colored to black to maintain the red-black properties ?
alt text http://img683.imageshack.us/img683/4929/rb1.jpg
thanks
The classic definition says the root has to be black, so it would have to be painted black to get that property. The basic idea is that red nodes are forbidden in certain locations (such as being a child of another red node), so painting a node red creates a potential constraint violation that should be checked for.
Related
So lately I've been analyzing the Red black tree and it's properties and trying to reason behind why they are like that, I understand that these constraints are used to keep the tree balanced and efficient while maintaining it's height,but still I can't find a way to clearly understand that why we rotate the tree only when the uncle of the newly inserted node is black? and why we only recolor it when it's uncle is red? I'm trying to understand the logic behind all these properties can anyone please explain them? Any help is much appreciated!
At least one rotation is needed during insertion when the uncle is black because there is a red-violation (two red nodes in a row) in this case but with the tree imbalanced no amount of re-coloring would fix it.
The simplest case
1b
\
2r
\
3r
1 and 2 each have a single leaf node (not shown), while 3 has two leaf nodes (also not shown). Ignoring node colors for a moment it is easy to see that a rotation is needed in order for this tree to balance, the recolorings that go along with that rotation are used to repair the red-black properties. When the second red node is out of alignment (right child of left child or left child of right child) a second rotation is needed because such a node is logically 'in between' its parent and grandparent.
With the tree:
2b
/ \
1r 3r
\
4r
The red node property is pushed up the tree because here no amount of rotation would fix the tree, any imbalance in the tree structure has to be at a level higher than what is shown here.
red black tree - insertion - z's uncle is red
Why is black height of node γ(gamma, the top most node) is unchanged after the operation?
I know how to explain why black height of T1 - T4 is the same after operation. But for gamma, I have absolutely no clue.
Anyone has ideas?
Okay so the insert of Alpha was done and it was coded red. Now after the insert the RB tree insertion code will check for imbalance between the red and black colors to determine if a rotation has to take place. After the check the Beta node was turned black, the Y node turned red and the gamma node turned black thereby keeping the tree RB balanced without need of rotation.
https://en.wikipedia.org/wiki/Red%E2%80%93black_tree
please see above wiki link to get a full explanation of how the color switches happen and why and how it helps determine rotation/s needed.
Wondering why for red black tree insert, we mark the new node as Red first, then do some adjustment? Why not mark it as Black and do some appropriate adjustment? Thanks.
I think the only reason is, adding a Red node will not break any rules of Red-Black tree on black node related rules (e.g. path from root to leaf contains the same number of black nodes), which only needs to adjust any violation of red rules (i.e. cannot be consecutive two red nodes for parent/child), which makes code simple. I do not think add a black node and adjust violations on number of black nodes (on different path) is impossible. In short, adding red node other than black is only for the purpose of code simplicity, no other reasons. If I am wrong, please feel free to correct me.
Inserting a red node is less likely to violate the red-black rules
than inserting a black one. This is because, if the new red node is
attached to a black one, no rule is broken. It doesn’t create a
situation in which there are two red nodes together which breaks
rule of red parent black children, and it doesn’t change the black
height(number of black nodes from root to leaf) in any of the paths.
Of course, if you attach a new red node to a red node, the rule of
red parent-black children will be violated. However, with any luck
this will happen only half the time. Whereas, if you add a new black
node, it would always change the black height for its path,
violating the black height rule.
Also, it’s easier to fix violations of red parent-black children
rule than black height rule.
Source: Data Structures & Algorithms in Java Second Edition - Robert Lafore page 437.
I was reading the red black tree tutorial from Eternally confuzzled.
In the part where author explains the deletion of the nodes from a RB tree, authors asks readers to find the explanation as exercise:
It's obvious after seeing a diagram how this restores balance by fixing the black heights, but it's confusing why 2 becomes red. Well, the red has to go somewhere or the black height of the tree would be affected, and the only known node that we are sure can be made red is that particular child. I don't quite remember how I figured out the red sibling cases, but I'm reasonably sure that alcohol was involved. :-) The second red sibling case looks at the inner child of the sibling. This child cannot be a null pointer (exercise: why?), so we simply test one of its children and act depending on which one is red. If the outer child is red, we perform a double rotation, color the new parent black, its right child black, and its left child red:
How did the author conclude that the inner child of the sibling cannot be a null pointer? Why that particular child cannot be null pointer ? Why not the other child ?
If it were null, the tree wouldn't be valid, as this property wouldn't be satisfied:
Every red node must have two black child nodes.
Why is this property important?
If we ignore this property, we could get a valid red-black tree looking like this:
B
\
R
\
B
\
R
\
B
\
...
This is of course the absolute worse-case for a binary search tree. It essentially makes it a linked-list - any operation would take O(n).
I too have this same doubt which #Tipps raised. My understanding is that the author doesn't mention the property "Every red node must have two black child nodes" in the write-up. The article infers the properties a RB-Tree must hold given that it was born out of a B-Tree.
Maybe the case itself doesn't exist ? and I used free simulators on the web to verify that such a single-black-child-red-parent case shouldn't ideally exist in a valid RB-Tree
"Those are only the cases where the sibling is black. If the sibling is red, it's even worse. But I have good news for you too. The following discussion doesn't matter except as an intellectual curiosity." - from the same article
If you observe the RB-Tree re-balancing code which takes out the red-sibling case, you would see that there is no special case handling. Though I still wonder why :
if ( new_root )
root = p;
else
root->link[dir] = p;
is necessary ? wouldn't the single rotation have taken care of this update already ?
In Red Black Tree Properties doesn't contain any rule for insert node color, how ever always we are inserting red color nodes.
If we insert black color node does it violate any Properties( any rule out of 4)?
Yep! Suppose you have a single node in your tree:
5 (black)
Now insert a new black node into the tree:
5 (black)
\
9 (black)
Now the invariant that every root-null path in the tree has the same number of black nodes is broken, since the path from the root left has one black node and the paths from the root right each have two.
Hope this helps!
You seem to be asking two questions
1) Why make nodes red when inserted (in title)?
2) Does inserting as black violate any properies?
You also seem to be under the mistaken impression that a Yes answer for 2) is an automatic justification for 1).
It is not so! Inserting a node as red also can violate one of the RB Tree properties. For instance, if you make the red node a child of another red node, you have just violated the property that red nodes can only have black children.
The reason for making it red, is that it is 'easier' to fix up the child node properties (by rotations and repainting parent/grandparents), rather than trying to fix up the path length properties. Perhaps another reason is that, that is what the authors came up with.
It might also be possible to fix up the tree by inserting a black node and not repainting red. Perhaps no one has given thought to it yet.