Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork8.1k
Improve docs on contourf extend#13047
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
jklymak commentedDec 25, 2018
This seems fine, but isn’t the underlying issue that the contour is not being updated automatically? |
timhoffm commentedDec 25, 2018
I don‘t know if that‘s possible. Does the cmap know about the associated scalar mappable? Otherwise there‘s no way that it can notify the QuadContourSet that it needs to update. |
| cs = plt.contourf(h, levels=[10, 30, 50], | ||
| colors=['#808080', '#A0A0A0', '#C0C0C0'], extend='both') | ||
| cs.cmap.set_over('red') |
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.
It is probably better to show updating the color map before creating the contour and then passing that in tocontourf. I think that is a bit for idiomatic and does not expose this updating edge-case in the examples.
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.
Ah, the point is we are creating the colormap on-the-fly so can not do that.
We have not noticed the lack of update on images because we unconditionally consult the colormap every time we draw.
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.
Updating aQuadContourSet on each draw (to get automatic updates and the same behavior as with images) would essentially mean that we have to run the full code ofchanged(). Not quite sure if we want to do this.
I'm just being defensive here and clearly document the current behavior.
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 agree this is the conservative path here.
jklymak commentedDec 29, 2018
I guess not. I wonder if what is actually needed is a |
timhoffm commentedDec 29, 2018 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
I guess not. Other possible API changes: It‘s actually not reasonable to define the over/under colors at another time compared to the regular colors. Therefore one could:
|
5d5eabd to8ebdfb1Compare8ebdfb1 tobb4b272Comparetimhoffm commentedJan 10, 2019 • edited
Loading Uh oh!
There was an error while loading.Please reload this page.
edited
Uh oh!
There was an error while loading.Please reload this page.
For now, I'd leave this as is and just clearly document the current behavior. This is what this PR is about. Everything else is beyond the scope of the PR (and not a battle I want to fight right now). So, by me, the PR is ready to go in. Note: Travis failure is due to#13137 and unrelated to this PR. |
…047-on-v3.0.xBackport PR#13047 on branch v3.0.x (Improve docs on contourf extend)
PR Summary
Based on#13038 I've rewritten the docstring for
contourfextendto better explain how to use it.