Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

MNT: Remove auto-flattening of input data to pcolormesh#24638

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

Merged
jklymak merged 1 commit intomatplotlib:mainfromgreglucas:pcolormesh-no-flatten
Jan 30, 2023

Conversation

greglucas
Copy link
Contributor

PR Summary

Opening this as a draft for discussion.

If someone passes in a 2-D array to.pcolormesh() should we automatically call.ravel() on it? See question from@jklymak here:#24619 (comment) Flattening is what historically has been done, but we've been moving towards QuadMesh being a primary 2-D collection lately and could get rid of this restriction on flattening input.

The updates here are all primarily surrounding what shapes the returned arrays are from the function calls and how to compare them, so drawing hasn't changed. Also note that this would introduce a deviation betweenpcolor(z2d).get_facecolors() == colors1d which returns the flattened array, whilepcolormesh(z2d).get_facecolors() == colors2d returns the original shape of the array passed in.

Collection classes have a lot of "1D list of objects" method handling in them, but inQuadMesh there is additional handling for the known 2-D structure of the arrays (mesh in the name).pcolor() returns aPolyCollection which is a 1D list of Polygons, and if there are masked elements it will actually shrink the list and not add that Polygon, so it would require more book-keeping (maybe adding a newPolyMeshCollection just for pcolor) to get the 2-D logic right.

PR Checklist

Documentation and Tests

  • Has pytest style unit tests (andpytest passes)
  • Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).
  • New plotting related features are documented with examples.

Release Notes

  • New features are marked with a.. versionadded:: directive in the docstring and documented indoc/users/next_whats_new/
  • API changes are marked with a.. versionchanged:: directive in the docstring and documented indoc/api/next_api_changes/
  • Release notes conform with instructions innext_whats_new/README.rst ornext_api_changes/README.rst

Comment on lines 1014 to +1025
# Turn it back on by restoring the array (must be 1D!):
pc.set_array(z.ravel())
pc.set_array(z.ravel() if pcfunc == plt.pcolor else z)
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Both of these situations feel undesirable...

  • Themust be 1D! is the way it currently is and doesn't feel right after we've initialized our array with the 2D versionpcolor(z).
  • It also doesn't feel great to change this and have to do theif pcfunc ... and change between 1D and 2D depending on which pcolor incantation I chose.

Copy link
Member

Choose a reason for hiding this comment

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

The flattening in pcolormesh is a historical artifact; I think the move to accept it as fundamentally 2-D is good.
Pcolor is rarely a better choice than pcolormesh. When it is, it is likely because it can generate a set of
colored quadrilaterals that don't have to fill out a 2-D domain. I think we should embrace this difference between
pcolormesh and pcolor, so I don't have a problem with your special-casing in the test. I'm open to discussing
ideas for backwards-compatible improvements to pcolor, so that it could also take a 2-D array in set_array,
but it doesn't seem like a priority.

@greglucasgreglucas added this to thev3.8.0 milestoneDec 15, 2022
@greglucasgreglucas marked this pull request as ready for reviewJanuary 19, 2023 02:35
@greglucasgreglucas mentioned this pull requestJan 19, 2023
1 task
Copy link
Member

@efiringefiring left a comment

Choose a reason for hiding this comment

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

Apart from the required rebase, I think this is fine.

@efiring
Copy link
Member

This is included in#25027, correct?

If someone passes in a 2-D array, we should keep that in the array data
@greglucas
Copy link
ContributorAuthor

This is included in#25027, correct?

Yes, I've rebased that PR onto this branch to get these updates.

Copy link
Member

@jklymakjklymak left a comment

Choose a reason for hiding this comment

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

Yay!

@mwaskom
Copy link

Ping; this PR apparently breaks seaborn (see issue linked above) and presumably other libraries that make assumptions about the shape of the data attached to artists added by axes functions.

I appreciate that there isn't a straightforward path to noisily warning about upcoming changes in artist properties, but could I ask that this change be delayed for at least a version cycle or two to allow downstream packages to adjust?

@greglucas
Copy link
ContributorAuthor

Thanks for the heads up. Note that this isn't targeted at 3.7, so we do have some time to think about the best approach here.

I guess we could warn wheneverget_facecolors() orget_array() would return a flattened array. But there wouldn't be a way to easily suppress the warning and get the new behavior without a temporary keyword argument which would then also require removal downstream later.

I agree, we should probably do some kind of warning/compatibility helper here.

@jklymak
Copy link
Member

Let's discuss on an issue?

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@efiringefiringefiring approved these changes

@jklymakjklymakjklymak approved these changes

Assignees
No one assigned
Projects
None yet
Milestone
v3.8.0
Development

Successfully merging this pull request may close these issues.

4 participants
@greglucas@efiring@mwaskom@jklymak

[8]ページ先頭

©2009-2025 Movatter.jp