Talk:Red–black tree

message: Property 1 is trivial.
Property 2 prevents the children of the root node from being red-black trees, since their roots may need to be recolored black.  This seems like an undesired property in a theoretical context.
Property 3 is useful, but only because it allows us to say "black" instead of "black or NIL" or "not red."
Properties 4 and 5 are the important invariants.
Given this, why not renumber the properties? 99.11.197.75 (talk) 00:42, 5 May 2011 (UTC)
thread_title:  Properties 

message: The following is from http://en.wikibooks.org/wiki/F_Sharp_Programming/Advanced_Data_Structures: 
                        B(z)
                        /  \
                      R(x)  d
                      /  \
                     a   R(y)
                         /  \
                        b    c
  
                         ||
                         \/
      B(z)              R(y)                 B(x)
      /  \              /  \                 /  \
    R(y)  d    =>     B(x) B(z)    <=       a   R(y)
    /  \              / \  / \                  /  \
  R(x)  c             a b  c d                 b   R(z)
  /  \                                             /  \
 a    b                                           c    d
                         /\
                         ||
                       B(x)
                       /  \
                      a   R(z)
                          /  \
                        R(y)  d
                        /  \
                       b    c
These changes are followed by recursion if R(y)'s new parent is also red.
The only other step is to recolor R(y) Black if it is the new root. 128.146.32.245 (talk) 00:08, 29 April 2011 (UTC)
thread_title:  Insert description more complicated than necessary? 

message: I think the following sentence from the formal proof is wrong (problematic part highlighted):
As such it has two children both of which have a black-height of either bh(v') or bh(v')-1 (depending on whether v' is red or black).
Given the definition of the black-height bh (relevant part highlighted):
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).
I think the black-height of the children is bh(v') or bh(v') - 1 depending on whether these children are red or black, and not depending on v' color.
Also, the sentence may be interpreted as if both children have the same color, which is not necessarily the case (the children may have different colors).
Can someone confirm? These details do not invalidate the proof, but they make it a bit harder to follow. Olivier Teuliere (talk) 10:16, 21 March 2011 (UTC)
replies: text: I made that edit, and you are correct. I'm sorry about that, I've reverted it. 193.77.101.149 (talk) 09:44, 23 July 2011 (UTC)
thread_title:  Mistake in the formal proof? 

message: It cannot be correct to say that if N is the new root then the tree is balanced. In a three element tree where all elements are black deleting the root node produces a tree where the black height is different on either left or right unless the child element is coloured red in an additional step. Or have I missed something here? 79.69.42.27 (talk) 21:23, 17 July 2010 (UTC)
replies: text: The various deletion cases all refer to a node with at most one (non-leaf) child. The case of nodes with 2 children (like in your example) is dealt with in the first paragraph of the "Removal" section. Olivier Teuliere (talk) 09:56, 21 March 2011 (UTC)
thread_title: Deletion error?

message: for completeness, adn to be able to see what is going on at one point, there should be implementations of the rotation functions available.  —Preceding unsigned comment added by 213.61.9.75 (talk) 09:20, 9 June 2010 (UTC)
thread_title:  rotate missing 

message: ::Note that the use of the leaf-nodes in the articles conflict with the link in the terminology section.--Loading 12:11, 11 May 2005 (UTC)
replies: text: Well, it's easy to say "black or missing" but it's not so easy to draw black or missing in the diagrams. I copied the nil leaf presentation from an online source, but it could be presented either way, it would just be a lot of work to change over and I don't see a particularly compelling reason not to do it this way. Deco 19:42, 14 May 2005 (UTC)

text: A very important information is missing: Red Black Trees are isomorphics to 2-3-4 Trees (B-Trees of order 4) (http://pedia.nodeworks.com/2/2-/2-3/2-3-4_trees/). 22:15, 28 May 2005 (UTC)

text: Go for it. I'll review your changes. Thanks for looking over this. Deco 00:39, 7 January 2006 (UTC)
thread_title:  Leaf nodes again 

message: I've now added some C code to this page. All this code has been compiled and thoroughly tested, not just against crashes but that the red-black properties are preserved after every single insert/delete operation. I tried to keep the code as simple and readable as possible, and in line with what the text and diagrams describe to the letter. I hope it adds some concreteness to the article. I chose C because it's good for this presentation, since it deals well with trees with parent pointers (cyclic data structures are kinda annoying in functional languages) and is familiar to most programmers. Deco 07:32, 4 August 2005 (UTC)
replies: text: Nice job! That'll help a lot in future implementations. However, in the Deletion part, you state "the insertion code works with either representation", i.e. designing leaf-nodes as node objects or NULL pointers. I think you rather meant the insertion algorithm, since you use constructions like child->color in the delete_one_child function and child may be a leaf if the original n (the one we deleted) had no non-leaf children. Similarly, calling any of the delete_caseX functions with a NULL pointer as parameter will cause problems. The code probably still works if you'd add the (admittedly irritating) if-statements everywhere to catch this case. Schellhammer 11:32, 4 August 2005 (UTC)
replies: text: Sorry, I meant the code in the insertion section. There was only one place in which a leaf could be encountered during insertion, but deletion turned out to be much trickier, because it may be that the parameter n is a leaf, which prevents me from accessing any of the surrounding nodes if it's represented with NULL. I would have to additionally pass in at least its parent, which requires updating the parent as we perform rotations, and it's just a mess. Deco 17:30, 4 August 2005 (UTC)
thread_title:  The code 

message: (copied from an e-mail sent to Deco by Pavel)
case 3.
if G was a root, you violate rule 2.
:Also, if its parent is red, it violates rule 4. This is mentioned in the text and the code, and used to be in the image, but I wanted to keep the image easy to update. I fixed the text to mention that it might violate rule 2 also, and to be clearer that we always recursively process G.
case 5.
path from leaf 4 and 5 contains 2 black nodes, path from other leafs contains 1 black nodes, that violates rule 5.
:The triangles are not meant to represent leaves but subtrees. Some subtrees have black circles at the top to indicate that their root must be black. The rotation does not alter the number of black nodes along any path (it is the same before and after), and so does not threaten rule 5. The reason rule 5 is not violated initially is that subtrees 4 and 5 are not as deep as subtrees 1, 2, and 3; in fact, the uncle may even be a leaf itself.
:If there's any way I can clarify this further please ask. Thanks again. Deco 14:16, 18 August 2005 (UTC)
thread_title:  Errors in algorithm 

message: According to the rules of a R-B tree, "both children of a red node are black". In the Case 4 example, N and P are both red after insertion.
:Case 4 does not complete the insertion, as you can see from the sample code - the node P is then processed using Case 5. The text says, "then, we deal with the former parent node P using Case 5". Deco 17:33, 17 October 2006 (UTC)
replies: text: I implemented the insertion algorithm in OCaml and verified that the indention was wrong, so I corrected it.Bill Smith 17:11, 26 November 2006 (UTC)
replies: text: The misleading indention was probably a result of tabs. There is no else. Your clarifications are welcome. Deco 14:42, 27 November 2006 (UTC)
thread_title:  Error in Insertion Case 4? 

message: A- This article isn't neutral
B- It uses "we" an unnecessary number of times.
::You need to actually provide instances of NPOV. You can't slap a template up there and expect us to guess at what you're talking about. I'm removing the template until you do so. TheWarlock 01:37, 9 May 2007 (UTC)
replies: text: Oh, and I forgot to mention: sign your posts. Put four tildes after your post so we know who you are. TheWarlock 01:38, 9 May 2007 (UTC)
replies: text: Should it still be changed to use a non-we structure? j.engelh 08:20, 11 May 2007 (UTC)
replies: text: It is preferable to have it use "we" than for it to be unintelligible but use the third-person out of grammatical tradition. If you can rephrase out the "we" and still have the article at least as understandable as it is now, go for it. TheWarlock 01:01, 12 May 2007 (UTC)

text: The use of "we" has nothing to do with NPOV. If you don't like the style feel free to fix it, just make it readable. Dcoetzee 20:06, 11 May 2007 (UTC)
replies: text: Just out of curiosity, what does "neutral" even mean when you're talking about a computer data structure?  Whether the math is correct?  I suppose you could argue over whether it or some other structure is best used in <something> - but that would necessarily mean an example, which either means it's citing someone else saying something, or it's OR, which is bad on the grounds that it's OR.  Now, maybe this article did have OR in it - the article itself reads like a chapter out of "Data Structures and Algorithms" by Weiss..  — Preceding unsigned comment added by Jimw338 (talk • contribs) 03:19, 27 March 2012 (UTC)
thread_title:  npov 

message: The article currently says
Note that this [call to insert_case1] is the only recursive call, and it occurs prior to any rotations, which proves that a constant number of rotations occur.
This is far from evident.  I'm not saying it's false that a constant number of rotations occur, only that this can't properly be called proof.  It's easy to imagine a recursive function that makes its recursive call before doing some chunk of work (like a rotation) and yields a linear number of chunks of work done.  For example, consider
postorder_tree_print(node n)
{
    postorder_tree_print(n->left);
    postorder_tree_print(n->right);
    print_node(n);
}
The only recursive calls occur before print_node, but calling postorder_tree_print on the root of a tree results in a number of calls to print_node equal to the number of nodes in the tree, which is not a constant.
Like Heawood reading Kempe's four-color proof, I'm smart enough to see the mistake but I'm not smart enough (or at least not interested enough) to fix it.
Pqrstuv 23:13, 1 July 2007 (UTC)
replies: text: The fact that it's the only recursive call, and that it returns immediately after calling it, is what makes this evident. Apologies for not being clearer - I'll attempt to reword it. Dcoetzee 00:31, 19 January 2008 (UTC)
thread_title:  Mistake in proof of correctness in Step 3? 

message: :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.). (Someone needs to fix this wording, since it is not true in its present form. It could be interpreted to mean that a path from node A to a descendant leaf would have the same number of black nodes as a path from node B to a descendent leaf. It must be made clear that the "from a node" is fixed but the "descendant leaf" is allowed to vary.)
The section from (Someone needs... has been removed because it's not part of the article, it's a comment on the article.  Text moved here so that someone who knows about the subject can hopefully fix it. -- Roleplayer (talk) 11:49, 18 January 2008 (UTC)
thread_title:  Removed from article 

message: The current article contains the iterative version (the version without using recursion) of implemenation of the removal operation. However, I doubt its usefulness because of the following reasons. Before removing the code, I would like to know what others think.
I do not think a long code like this fits well in the Wikipedia. The aim of the article is not to build a ready-to-use library, but to explain clearly what a red-black tree is, including how it works and how it is used. The article does its job well without this code.
It contains a small bug. In the lines
/* delete_case3(n): */
//s = sibling(n);//not needed
the assignment to s is needed, as is explained in the text of case 2. I hesitate to correct just this because I am not sure about the correctness of the other part.
IMHO this code is hard to understand because almost everything is written inside the single for(;;) loop. Cases 4–6 (and possibly also case 2) should be moved out of the loop for better readability.
In addition, I do not see any reasons to include the iterative implementation only for the removal operation and not for the insertion operation. If the current code ever helps understanding of how removal works, then I think the iterative implementation of insertion would also be helpful. --fcp2007 (talk) 14:31, 4 May 2008 (UTC)
replies: text: I personally am using the iterative implementation in benchmarks vs treaps.  I find it very useful.  It's kind of funny... I only read this discussion because I wanted to post about the bug described above!  The same bug exists in case 6. Smilindog2000 (talk) 14:48, 21 May 2008 (UTC)

text: I agree about removing the iterative implementation personally. Nobody should be using code from Wikipedia articles, they're not appropriately licensed - the code is only there to explain the concepts. Dcoetzee 02:07, 25 December 2008 (UTC)
thread_title:  Iterative implementation 

message: I find that pseudo-code would be far more appropriate for this article. After all, the article is about a data structure and the theory behind implementing it. A reference implementation should be hosted elsewhere, not inside an encyclopedia. I would recommend replacing the C code with pseudo-code, however I didn't want to do this myself until certain everybody agrees. -- Jerome Baum  —Preceding unsigned comment added by 77.176.73.67 (talk) 01:19, 15 December 2008 (UTC)
replies: text: There used to be pseudocode. I replaced it with C code fragments originally because of a series of spurious "fixes" that made the cases incorrect; it was the only way I could verify with any certainty that the code was valid, since with runnable code these fixes could be tested. However, nowadays I've moved more towards using pseudocode and the code block templates to control spurious fixes. I think the article should also give more attention to the diversity of different methods for implementing the operations, and to various choices that can be made for the properties. Dcoetzee 01:50, 25 December 2008 (UTC)
thread_title:  C code vs. pseudo-code 

message: Paper title: Symmetric binary B-Trees: Data structure and maintenance algorithms
there is a pdf available here for 34 bucks.
http://www.springerlink.com/content/qh51m2014673513j/  —Preceding unsigned comment added by 140.177.205.91 (talk) 20:55, 14 August 2009 (UTC)
thread_title:  citation for Rudolf Bayer 

message: The fifth listed property under "Properties" gave me long pause. Red-black trees do not contain cycles. Qualifying "paths" with "simple" suggests otherwise, and merely confused me. Is there any reason "simple" should not be deleted? Strebe (talk) 20:42, 12 April 2010 (UTC)
replies: text: I think the intended meaning is that the path does not repeat edges. For example, it doesn't go from the root down to the leaf, then back up, then back down to some other leaf (this is normally called a walk). In the context of binary trees I think this clarification is unnecessary. Dcoetzee 21:31, 14 April 2010 (UTC)
thread_title: "Simple path"?

message: I am very new to this subject, but with careful study, I am able to follow this article. However I found insertion case 4 to be quite confusing. It took a little too much pondering and a little guessing to get to where I think I understand it. A couple points:
1) Unlike all the other cases, this case doesn't appear to ever complete any insertions. This is kinda confusing in itself. So I suggest that it is explained that this step does not solve a particular case, but rather converts the case, so it's the same as case 5. (I would do this edit myself if I was sure I'm right about what's going on.)
2) The language makes this step sound optional. ie it says that the rotation "can be performed" not "must be performed" or "is performed". This coupled with my confusion as to why this is being done in the first place makes for a confused me. So I suggest that this step be made explicitly mandatory (assuming I'm right and it is.)
I hope the above feedback enables someone to make this article even more clear.
Thank you,  - JasonWoof (talk) 02:12, 19 April 2010 (UTC)
thread_title:  Is insertion case 4 mandatory? why? 

message: >> Case 3: P, S, and S's children are black
We remove N and all N's childs are leafs, so if P ans S are black, S's children should be leafs too(becouse we must have the same number of black nodes on every path).
On the picture we see them as nodes that have children...  —Preceding unsigned comment added by 91.103.66.4 (talk) 16:32, 18 May 2010 (UTC)
thread_title:  Removal:case 3 

message: When inserting 3, 2, 1 in order you get the following tree:
  3[black] (child: 2[red] (left: 1[red]))
And then you run into case 5, which attempts to rotate using 1's grand parent (3) as pivot, which fails, because 3 has no parent. In this case, 2 should have been the pivot.
So the wording instead of:
:  In this case, a right rotation on the parent of P is performed;
should be
:  In this case, a right rotation on the parent of P, G is performed, if G is not the root node. In that case, a rotation on P is performed.
And the code accordingly
  rotate_right( g->parent ? g : n->parent );
  rotate_left( g->parent ? g : n->parent );
Also it should be clarified that the "rotate_"-functions use the Pivot as the argument (which is the explained in Tree rotation)
--77.8.172.59 (talk) 02:59, 20 May 2010 (UTC)
thread_title:  Incomplete case 5 

message: According to the wiki:
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)).
Shouldn't it be to maintain Property 4? As Property 5 isn't violated by the addition of a red node.
Edit: After proper analysis I think both Properties should be mentioned. Property 4 for the reason why P and U are turned black and Property 5 for the reason why G turns red.
RevoltPT (talk) 15:04, 11 June 2010 (UTC)
thread_title:  Insertion Case 3 

message: The "often" in "In the C++ Standard Template Library, the containers std::set<Value> and std::map<Key,Value> are often based on red-black trees" does not make sense to me...134.58.42.46 (talk) 15:34, 22 December 2010 (UTC)
replies: text: Most (possibly all) implementations of these STL containers use red-black trees, but any data structure that fulfills the behavioral requirements could be used. Hence, “often”. Strebe (talk) 19:04, 22 December 2010 (UTC)
replies: text:  I'll change it to "typically". (Prevents giving the impression that any red-black implementation might actually turn out to be based on a different data structure on Wednesdays and bank holidays.)  Card Zero  (talk) 08:26, 7 February 2011 (UTC)
thread_title:  C++ reference 

message: We're referring to this paragraph:
"The complex case is when both M and C are black. (This can only occur when deleting a black node which has two leaf children, ..... (S cannot be a leaf because if N is black, which we presumed, then P's one subtree which includes N counts two black-height and thus P's other subtree which includes S must also count two black-height, which cannot be the case if S is a leaf node)."
Our comments: Since N, which used to be called C, is a leaf, P's one subtree which includes N can not count two black heights as stated in the original article.
Also note that this changes a lot of the cases in the Removal procedure.  For example, any figure that shows N having subtrees hanging from it is incorrect.
In fact, in case M and C are both black, perhaps the way to do Removal is just to replace M with C, thereby messing up the black height.  This is then to be followed by some form of black height rebalancing which we haven't thought out completely.
Vitit Kantabutra, Idaho State University, Pocatello, ID, U.S.A.
Vkantabu (talk) 20:12, 3 November 2011 (UTC)
thread_title:  Possible Error in "Removal" Section 

message: Hi,
In the section Red-black_tree#Properties, it's said in point 3 number that "All leaves are the same color of the root".
However, on the red black tree example picture, there are 3 leaves which are red. What did I miss? :)
Regards,
J 195.83.155.55 (talk) 03:31, 28 May 2012 (UTC)
replies: text: Nodes are circles; leaves are boxes. Glrx (talk) 18:03, 30 May 2012 (UTC)
thread_title:  "All leaves are the same color of the root" 

message: Source: https://www.coursera.org/learn/algorithms-graphs-data-structures/lecture/8acpe/red-black-trees - Coursera Graph Search, Shortest Paths, and Data Structures course by Tim Roughgarden of Stanford
At about 5:08 in this lecture Tim explains the origin of the name as he had asked the question to Guibas. Indeed it acquired the name from the paper mentioned in the article. The reason was due to new limited colour printing technology of the journal which the authors were keen to use and have red and black pictures of the structure. The story has a twist in that due to a problem the technology wasn't available for use, but the name stuck.
Sedgewick explains the naming here in Algorithms, Part 1: https://class.coursera.org/algs4partI-002/lecture/50 at 31:55  — Preceding unsigned comment added by 82.34.15.102 (talk) 09:16, 10 March 2013 (UTC)
thread_title:  Origin of name 

message: I know why: Because it would cause there to be 3 black nodes from the root node to the leaves for the leaves attached to U, as opposed to 2 black nodes elsewhere.  The only thing is, How would the program know not to create nodes?  Does it check all the paths or something?  --Cornince (talk) 11:03, 27 May 2013 (UTC)
thread_title:  How does U in case 4 not have any leaves? 

message: The article says "Red–black trees are also particularly valuable in functional programming, where they are one of the most common persistent data structures" which is wrong. The most used data structure is AVL trees because they are simpler and support set operations easily. Currently in the functional programming standard libraries
- AVL are used by OCaml, FSharp
- Red-black are used by SML-NJ
- Size balanced trees are used by Haskell  — Preceding unsigned comment added by 90.46.151.222 (talk) 01:26, 12 December 2013 (UTC)
thread_title:  Usage in functional programming 

message: The last paragraph in "Analogy to B-trees of order 4" states that "The worst case occurs when all nodes in a colored binary tree are black, the best case occurs when only a third of them are black (and the other two thirds are red nodes)." This is untrue; when all nodes in a red-black tree are black then by the 5th property the tree is perfectly balanced. The worst case is instead when the tree is most unbalanced, when one side of root it all black and the other half only a third black.
I feel as though my intuition is failing me in the very last sentence above, but besides that is the article actually incorrect in what it says.
-Node  — Preceding unsigned comment added by 129.2.129.93 (talk) 22:29, 28 September 2014 (UTC)
replies: text: I guess you're mixing up execution time and fill factor. What is talked about is: fill factor. --Nomen4Omen (talk) 09:23, 1 November 2018 (UTC)
thread_title:  Incorrect information? 

message: Property 4 has been changed from "(This property means that node colored red cannot be in a row.)" to "This property means that a node that is colored red cannot be in a black row." But either way: What is a row in a red–black tree ? --Nomen4Omen (talk) 09:41, 2 September 2015 (UTC)
thread_title:  What is a row or a black row? 

message: Is the color exchange in delete_case5 actually necessary? As far as I can tell the delete_case5 sibling and near nephew nodes always have their colors re-assigned in delete_case6.
If delete_case5 rotated  then "s" in delete_case6 was the near nephew in delete_case5 and the node that is the far nephew in delete_case6 (the one re-colored inside the delete_case6 if block) was s in delete_case5.
If that understanding is correct then I see no reason for delete_case5 to bother assigning colors.
Soronel~enwiki (talk) 19:32, 9 February 2016 (UTC)
replies: text: I guess you are right in essence. And the implementation could be optimized in this way, especially because there are no color tests left in delete_case6. There may be more such optimizations possible in the algorithm. However, the goal of the text is not code optimization, it is clarity. --Nomen4Omen (talk) 21:16, 9 February 2016 (UTC)
thread_title:  Question about delete_case5 and delete_case6 

message: @:user:Henryy321 Could you pls show the point where the "duplicates" of  and  are suppressed in the function
:union(t1, t2) ?
A similar question arises with intersection and difference, but may be answered by the previous answer. --Nomen4Omen (talk) 07:57, 14 December 2016 (UTC)
thread_title:  Set operations and bulk operations 

message: The current "Applications and related data structures" section  reads:
The performance measurements of Ben Pfaff with realistic test cases in 79 runs find AVL to RB ratios between 0.677 and 1.077, median at 0.947, and geometric mean 0.910.
This sentence doesn't state clearly whether AVL trees or RB trees are better. Also, the numbers are not found in the reference cited.
Could someone clear this paragraph up?
--MaigoAkisame (talk) 03:20, 6 December 2017 (UTC)
thread_title:  Performance comparison with AVL trees 

message: This article mentions a replace_node function, but has no source code showing how that works.  Since other algorithms are explained in source code, it would seem to make sense for this algorithm to also be explained in source code. - Gilgamesh (talk) 16:18, 23 December 2017 (UTC)
replies: text: Simple enough, just find the node and change the contents. We don't need to do anything else, because we haven't changed the structure.50.28.190.226 (talk) 21:30, 20 March 2018 (UTC)
thread_title:  replace_node code missing 

message: Did anybody notice that as far as I can tell User:David_of_Earth introduced a LEAF constant that is not defined anywhere? I suppose it is meant to be NULL but I am mildly struggling to follow the presented algorithm... --Sven Pauli (talk) 18:40, 3 January 2019 (UTC)
replies: text: Yes, just #define it as NULL and all appears to work fine.  I have taken the liberty of adding the basic types as used in the code, without which it is more difficult to follow.  I also updated the info on libavl.  The link to Eternally Confuzzled appears to be down, but I left it in in case that is just a temporary thing.  If it is still down in a couple of month's time, perhaps remove it then.  82.13.91.100 (talk) 09:02, 27 June 2019 (UTC)
thread_title:  LEAF...anybody? 

message: The proposed leaves are no individuals, nowhere in the article. They all have the same value, either NULL or the address of the ONE sentinel node. (Maybe it is helpful to call this type LEAF.) They do not contain a key or data. Nevertheless, they are considered a black unity for easier counting of the black nodes in the path.
The difficult case of delete, black node without child, has to replace the latter by a such a LEAF. –Nomen4Omen (talk) 19:03, 16 February 2021 (UTC)
thread_title:  Changes as of Feb 16th 21 

message: The article suggests two possible sources for the name of Red-black trees. But this video by Prof.Tim Roughgarden who was a colleague of Prof.  Leonidas J. Guibas, suggests both reasons might be wrong. In this video from coursera, at the 5:08 mark, you can hear a second hand account from Prof. Tim say that, the name came about because when the inventors were writing the article for a journal which was going to use some new technology that allowed them to print in limited colors (red and black). So they prematurely named their data structure as red-black trees, but they ended up not being able to use the new printing method anyway.
This above story is not corroborated by other accounts found on stackexchange, one of which is from Prof. Leonidas himself which says they did it because they had black and red pens! Prof Sedgedwick seems to say it's because of the laser printer at Xerox PARC.
Hazkaz (talk) 12:42, 11 June 2021 (UTC)
thread_title:  Conflicting History behind the name of Red-black trees 

message: # Introduction of a case synopsis for insert and delete with each column explained
# Cases again renumbered
# More consistent wording
# Pull-out of first iteration clearer
# Case defining code at the top of the section
―Nomen4Omen (talk) 15:02, 24 July 2021 (UTC)
thread_title:  Changes as of 2021-07-24 

message: Your proposal may be more easily understandable. But it has the big disadvantage that the RB software has to know what the user data are, in other words: it is NOT generic. If the RB software touches and changes ONLY the RB pointers and RB data it can deal with any kind of user layout (which potentially can be extremely complicated). This has been the intention of the version before your change and would not be achievable with your version. –Nomen4Omen (talk) 18:36, 29 December 2021 (UTC)
replies: text: That's fair enough. However, the version prior to my edit seems misleading: it says "all red–black tree pointers of this node and N are exchanged". It is not enough to simply exchange left/right/parent pointers of N and the replacement node, you would also have to update N's parent child pointer and the parent pointers of both nodes' children, and you would also need to exchange the colors of the two nodes (after all you are basically changing everything except the node key and user data). Of course, simply swapping keys and pointers to user data is much simpler than all of this dance, but as you say it would require the implementation to know that user data exists. You can revert my edit if you wish, but I'd suggest rephrasing the paragraph regardless. – Mebeim (talk) 19:24, 29 December 2021 (UTC)
thread_title:  Changes as of 16:53, 29 December 2021 

message: The info box names R. Bayer&1972.
Paragraph History associates both with 2–4 trees, and names  L.J. Guibas & R. Sedgewick for publishing red–black trees in 1978. 178.6.237.24 (talk) 13:04, 28 July 2022 (UTC)
replies: text: As I interpret it: The scientific community agrees that Bayer did not name his tree RB-tree, nevertheless is considered its inventor because his invention and analysis is extremely close to RB-trees. In 1978 Guibas and Sedgewick rebaptized Bayer's symmetric binary B-tree to RB-tree. −Nomen4Omen (talk) 14:42, 28 July 2022 (UTC)
thread_title:  Inventor & year of invention 

message: This page uses i. .e., i .e. and e. g.. For the first two of i. .e. and i. e. this seems to be inconsistent. Checking the style guides acronym section, I was able to find that the specific first two examples should be ie. and the last should be e.g..
Since these currently seem to be inconsistent, I'm going to make a preliminary edit to change them to what is shown in the manual of style's table. (This post is mostly to say my reasoning in case I'm wrong) KindlingFlame (talk) 06:51, 6 March 2024 (UTC)
thread_title:  i.e. versus i. .e. 

message: "Sedgewick originally allowed nodes whose two children are red, making his trees more like 2–3–4 trees, but later this restriction was added"
What does "this restriction" refer to? Gwideman (talk) 11:44, 30 March 2024 (UTC)
replies: text: The 'restriction' added later is that 'a black node may not have two red children. This means that only 2-nodes and 3-nodes are allowed, making them isomorphic to 2-3 trees instead. Left-leaning RB-trees have a 2-3 version and a 2-3-4 version. Ordinary RB-trees also have a 2-3 version and a 2-3-4 version. IntGrah (talk) 19:48, 26 April 2024 (UTC)
thread_title:  History section confusion 

message: There is a section titled "B-trees of order 4". Would it not be clearer to just say "2–3–4 tree" instead, given that most textbooks introduce 2–3–4 trees first? I.e.
: Red–black trees are similar in structure to 2–3–4 trees (B-trees of order 4), ...
and proceed in the rest of the section to refer to them as 2–3–4 trees
IntGrah (talk) 19:53, 26 April 2024 (UTC)
thread_title:  "B-trees of order 4" versus "2–3–4 tree"