Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Jan 14, 2019
Merged

Improve docs on contourf extend #13047

merged 1 commit into from
Jan 14, 2019

Conversation

timhoffm
Copy link
Member

PR Summary

Based on #13038 I've rewritten the docstring for contourf extend to better explain how to use it.

@timhoffm timhoffm added this to the v3.0.3 milestone Dec 25, 2018
@jklymak
Copy link
Member

jklymak commented Dec 25, 2018

This seems fine, but isn’t the underlying issue that the contour is not being updated automatically?

@timhoffm
Copy link
Member Author

This seems fine, but isn’t the underlying issue that the contour is not being updated automatically?

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.

tacaswell
tacaswell reviewed Dec 25, 2018
View reviewed changes
lib/matplotlib/contour.py

cs = plt.contourf(h, levels=[10, 30, 50],
colors=['#808080', '#A0A0A0', '#C0C0C0'], extend='both')
cs.cmap.set_over('red')
Copy link
Member

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 to contourf. I think that is a bit for idiomatic and does not expose this updating edge-case in the examples.

Copy link
Member

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.

Copy link
Member Author

@timhoffm timhoffm Dec 25, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating a QuadContourSet 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 of changed(). Not quite sure if we want to do this.

I'm just being defensive here and clearly document the current behavior.

Copy link
Member

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
Copy link
Member

jklymak commented Dec 29, 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.

I guess not. I wonder if what is actually needed is a cs.set_over, cs.set_under method if users really need to do this after the fact?

@timhoffm
Copy link
Member Author

timhoffm commented Dec 29, 2018 •
edited
Loading

I guess not. cs.set_under and similar seem counter-intuitive, when there‘s already a cs.cmap.set_under with a different behavior. It‘s not obvious that one can use one but not the other. That would be my least favorite solution if we‘re going to change the API.

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:

  • add additional kwargs for over/under to contourf, or
  • Make it reasonably simple to create a cmap and norm for a discrete set of colors and boundaries. These could then be supplied to contourf.

@timhoffm timhoffm force-pushed the doc-contourf-extend-cmap branch from 5d5eabd to 8ebdfb1 Compare January 6, 2019 19:14
@timhoffm timhoffm force-pushed the doc-contourf-extend-cmap branch from 8ebdfb1 to bb4b272 Compare January 6, 2019 22:55
@timhoffm
Copy link
Member Author

timhoffm commented Jan 10, 2019 •
edited
Loading

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.

@tacaswell tacaswell merged commit 6b3c015 into matplotlib:master Jan 14, 2019
meeseeksmachine pushed a commit to meeseeksmachine/matplotlib that referenced this pull request Jan 14, 2019
@tacaswell
Backport PR matplotlib#13047: Improve docs on contourf extend
0724082
@meeseeksmachine meeseeksmachine mentioned this pull request Jan 14, 2019
Merged
@timhoffm timhoffm deleted the doc-contourf-extend-cmap branch January 15, 2019 20:24
dstansby added a commit that referenced this pull request Jan 20, 2019
@dstansby
Merge pull request #13176 from meeseeksmachine/auto-backport-of-pr-13…
5b18170 
…047-on-v3.0.x

Backport PR #13047 on branch v3.0.x (Improve docs on contourf extend)
@rcomer rcomer mentioned this pull request Jun 3, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@tacaswell tacaswell tacaswell left review comments

Assignees
No one assigned
Labels
Documentation
Projects
None yet
Milestone
v3.0.3
Development

Successfully merging this pull request may close these issues.
4 participants
@timhoffm @jklymak @tacaswell @QuLogic