Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
FIX: colorbar with boundary norm, proportional, extend#20987
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
a00b49b toacb101eCompareThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Looks good to me, and I think the image test makes sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Optional comments.
| cmap = mcolors.ListedColormap(['r', 'g', 'white', 'g', 'r']) | ||
| cmap.set_under('yellow') | ||
| cmap.set_over('cyan') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
sure
| style='mpl20') | ||
| def test_proportional_colorbars(): | ||
| x = y = np.arange(-3.0, 3.01, 0.025) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Since you have limited numeric precision, the results are only approximately the same. Forarange you often don't get expected "exact" numbers. e.g. the middle value is 0 withlinspace but 1.06e-14 witharange. 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 effectsis 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 tof41edb6CompareOwee, 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 tosuggest an improvement. |
…987-on-v3.5.xBackport 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).