FIX: colorbar with boundary norm, proportional, extend #20987
Conversation
a00b49b to
acb101e
Compare
| cmap = mcolors.ListedColormap(['r', 'g', 'white', 'g', 'r']) | ||
| cmap.set_under('yellow') | ||
| cmap.set_over('cyan') |
There was a problem hiding this comment.
Optional, but the test is stonger if you break the symmetry of the colors. With the symmetry, you cannot check the sign.
| cmap = mcolors.ListedColormap(['r', 'g', 'white', 'g', 'r']) | |
| cmap.set_under('yellow') | |
| cmap.set_over('cyan') | |
| cmap = mcolors.ListedColormap( | |
| ['0.3', '0.5', 'white', 'lightblue', 'steelblue']) | |
| cmap.set_under('darkred') | |
| cmap.set_over('crimson') |
Also, I've chosen colors that hurt the eye a little less 😄
| style='mpl20') | ||
| def test_proportional_colorbars(): | ||
|
|
||
| x = y = np.arange(-3.0, 3.01, 0.025) |
There was a problem hiding this comment.
| x = y = np.arange(-3.0, 3.01, 0.025) | |
| x = y = np.linspace(-3, 3, 241) |
np.arange with non-integer step is generally not recommended
https://numpy.org/doc/stable/reference/generated/numpy.arange.html:
When using a non-integer step, such as 0.1, the results will often not be consistent. It is better to use numpy.linspace for these cases.
While it doesn't matter for the test, let's set a good example.
There was a problem hiding this comment.
I guess I don't understand this advice. Very often one wants to specify dx instead of N. Sure you can compute one from the other, but I don't see why one would be more consistent than the other.
There was a problem hiding this comment.
Since you have limited numeric precision, the results are only approximately the same. For arange you often don't get expected "exact" numbers. e.g. the middle value is 0 with linspace but 1.06e-14 with arange. Additionally, the "endpoint not included" feature makes sense for indices, but is a somewhat awkard API for (float)numeric sequences. And in conjunction with the numeric jitter, this can have surprising effects; e.g. https://stackoverflow.com/questions/10011302/python-numpy-arange-unexpected-results.
There was a problem hiding this comment.
Sure, that's just floating point arithmetic. I'm not convinced that makes arange bad style or "inconsistent"
There was a problem hiding this comment.
Well, "inconsistent" is numpy's description. That may not be the best term.
However, that the endpoint and number of points depend on small numeric effects is highly problematic. Practically, you don't know what you will get if endpoint is start + N times interval.
Anyway, I'm not going to argue more about this within a test.
acb101e to
f41edb6
Compare
…rtional, extend
|
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulation you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon! Remember to remove If these instruction are inaccurate, feel free to suggest an improvement. |
…987-on-v3.5.x Backport PR #20987 on branch v3.5.x (FIX: colorbar with boundary norm, proportional, extend)
|
It never worked, so I don't think we should go through the trouble of figuring out the backport. |
|
Agreed. The back port would be really hard given the changes to colorbar in 3.5 |
PR Summary
Colorbars with a Boundary norm and extend != 'none' were not working because the normalization included the extend boundaries, which are very very big. Normalizing with just the inside boundaries is the right thing to do.
Added an image test because I don't really know how to test this without, and this functionality is not well-tested elsewhere.
Closes #20963
PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).