There are 100+ test failures from this (which is more like 30-40 unique tests once the pdf/png/svg sets are taken into account) where one of the overlapping colors is used. I am inclined to change the tests to use the 'short' colors which will still have the highest priority.

Minimizing test image replacements this way sounds fine to me.

I noticed that there was a lot of missed overlap in color names due to xkcd having space in their names. Fixing that, they basically all clash (cyan, white, and black are the same)

Having so many clashes doesn't really bother me. (i.e. having lots of clashes vs. a few clashes feels like the same about of problem in my mind).

I agree with Eric -- fixing the test source code to force use of the old colors is way preferable over a mass regeneration of images for a sort of "unimportant" (unlikely to uncover bugs) reason.

I had not realized initially that the X11 names are also the HTML / CSS
names. I think that is a pretty strong argument for defaulting to those
names over the XKCD names.

On Mon, Jan 4, 2016 at 10:24 AM Michael Droettboom notifications@github.com
wrote:

Having so many clashes doesn't really bother me. (i.e. having lots of
clashes vs. a few clashes feels like the same about of problem in my mind).

I agree with Eric -- fixing the test source code to force use of the old
colors is way preferable over a mass regeneration of images for a sort of
"unimportant" (unlikely to uncover bugs) reason.

—
Reply to this email directly or view it on GitHub
#5775 (comment)
.

The current round of failures is caused by floats not round-tripping to rbg floats, ex

In [15]: import matplotlib.colors as mc

In [16]: mc.hex2color(mc.rgb2hex((0, .5, 0)))
Out[16]: (0.0, 0.5019607843137255, 0.0)

In [17]: mc.hex2color(mc.rgb2hex((0, .75, 0.75)))
Out[17]: (0.0, 0.7490196078431373, 0.7490196078431373)

and in my attempt to simplify handling of the single letter mappings I converted the hard-coded tuples to hard-coded hex values. This is what is causing the tiny differences. Interestingly, I think this mean 'g', 'y', 'm' have always been slightly different than their named counterparts.

I think all we need to ensure is that the precision of the hex numbers (8-bits per plane) is retained. Most of our displays can't display more precision than that anyway.

assert mc.rgb2hex(mc.hex2color(color)) == color

should hold true. But the inverse doesn't really matter.

I suspect the failed tests where cases where anti-aliasing was involved and 1 bit got changed.

In [116]: ll = [str(i) for i in range(10)] + ['a', 'b', 'c', 'd', 'e', 'f']

In [117]: h = map(lambda x: '#'+''.join(x), itertools.product(*([ll] * 6)))

In [118]: import matplotlib.colors as mc

In [119]: for _ in h:
   .....:     assert _ == mc.rgb2hex(mc.hex2color(_))
   .....: 

This completes sucessfully, but take too long to run to be worth putting in the test suite.

Yes, 'g', 'y' and 'm' have always been slightly different. I don't know the
full reasons, but it has been that way for as long as I can remember.

On Mon, Jan 18, 2016 at 8:46 PM, Thomas A Caswell notifications@github.com
wrote:

In [116]: ll = [str(i) for i in range(10)] + ['a', 'b', 'c', 'd', 'e', 'f']

In [117]: h = map(lambda x: '#'+''.join(x), itertools.product(*([ll] * 6)))

In [118]: import matplotlib.colors as mc

In [119]: for _ in h:
.....: assert _ == mc.rgb2hex(mc.hex2color(_))
.....:

This completes sucessfully, but take too long to run to be worth putting
in the test suite.

—
Reply to this email directly or view it on GitHub
#5775 (comment)
.