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.

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

Merged
merged 1 commit into from
Jan 14, 2019
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 36 additions & 8 deletions lib/matplotlib/contour.py
Original file line number Diff line number Diff line change
Expand Up @@ -1766,14 +1766,42 @@ def _initialize_x_y(self, z):
are not given explicitly via *levels*.
Defaults to `~.ticker.MaxNLocator`.

extend : {'neither', 'both', 'min', 'max'}, optional
Unless this is 'neither', contour levels are automatically
added to one or both ends of the range so that all data
are included. These added ranges are then mapped to the
special colormap values which default to the ends of the
colormap range, but can be set via
:meth:`matplotlib.colors.Colormap.set_under` and
:meth:`matplotlib.colors.Colormap.set_over` methods.
extend : {'neither', 'both', 'min', 'max'}, optional, default: \
'neither'
Determines the ``contourf``-coloring of values that are outside the
*levels* range.

If 'neither', values outside the *levels* range are not colored.
If 'min', 'max' or 'both', color the values below, above or below
and above the *levels* range.

Values below ``min(levels)`` and above ``max(levels)`` are mapped
to the under/over values of the `.Colormap`. Note, that most
colormaps do not have dedicated colors for these by default, so
that the over and under values are the edge values of the colormap.
You may want to set these values explicitly using
`.Colormap.set_under` and `.Colormap.set_over`.

.. note::

An exising `.QuadContourSet` does not get notified if
properties of its colormap are changed. Therefore, an explicit
call `.QuadContourSet.changed()` is needed after modifying the
colormap. The explicit call can be left out, if a colorbar is
assigned to the `.QuadContourSet` because it interally calls
`.QuadContourSet.changed()`.

Example::

x = np.arange(1, 10)
y = x.reshape(-1, 1)
h = x * y

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

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.

cs.cmap.set_under('blue')
cs.changed()

xunits, yunits : registered units, optional
Override axis units by specifying an instance of a
Expand Down