lkml.org 
[lkml]   [2020]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Tech-board-discuss] [PATCH] CodingStyle: Inclusive Terminology
On Mon, 6 Jul 2020 11:22:10 -0400
Arvind Sankar <nivedita@alum.mit.edu> wrote:

> Though I'm not sure if blueprint translates literally into other
> languages, it did actually have a logical reason, viz engineering
> drawings used to be blue/white. But logical reasons don't have to exist.
> In the case of colors, for example, using red-black tree doesn't exclude
> blind people, precisely because there is no logical reason for using the
> colors red and black, or even colors at all, so it's not as if you gain
> any additional insight into the structure if you are able to see the
> colors. It just needs _some_ arbitrary labels for distinguishing two
> classes of nodes, it could just as well have been named A-B tree or 0-1
> tree or whatever. I don't think there is any concise way to label them
> that conveys anything useful about how they're used in the data
> structure -- you just have to learn about the structure and how it's
> used. This isn't the case with whitelist/blacklist, where those colors
> actually have connotations about what the two lists mean.

When I learned about R-B trees in my algorithms class decades ago, I
distinctly remember the text book saying something about how the red
and black names were meaningless. Just know that the nodes are
different in how you go about sorting or injecting a new node into the
tree. So yes, it could have been blue and yellow, or 1 and 0, or Bob
and Alice. The colors were just a way of labeling in order to
differentiate the two types of nodes, and I am not worried that people
are going to take offense to them.

-- Steve

\
 
 \ /
  Last update: 2020-07-06 17:40    [W:0.099 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site