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

Fix BoundaryNorm cursor data output#22835

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 5 commits intomatplotlib:mainfromyumasheta:fix-BoundaryNorm-mappable
Jun 23, 2022

Conversation

yumasheta
Copy link
Contributor

@yumashetayumasheta commentedApr 12, 2022
edited
Loading

PR Summary

This shouldfix#21915 with anisinstance(norm, BoundaryNorm) check and special logic to figure out thedelta for calculating the value for the significant digits to show as cursor data output.
I opted to use the boundaries of theBoundaryNorm directly, instead of calculating the midpoints of neighboring regions (midpoint is done in the non-BoundaryNorm cases).
I also added tests inlib/matplotlib/tests/test_artist.py::test_format_cursor_data_BoundaryNorm. For the tests I compare the cursor data output to identically formatted strings with fixeddelta taken as the stepping ofnp.linspace that is used to create the boundaries forBoundarNorm. The fixeddelta values are not identical to what this PR computed, but should give identical output for the strings.

PR Checklist

Tests and Styling

  • Has pytest style unit tests (andpytest passes).
  • IsFlake 8 compliant (installflake8-docstrings and runflake8 --docstring-convention=all).

Documentation

  • [ N/A] New features are documented, with examples if plot related.
  • [ N/A] New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).
  • [ N/A] API changes documented indoc/api/next_api_changes/ (follow instructions in README.rst there).
  • [ N/A] Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).

Copy link

@github-actionsgithub-actionsbot left a comment

Choose a reason for hiding this comment

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

Thank you for opening your first PR into Matplotlib!

If you have not heard from us in a while, please feel free to ping@matplotlib/developers or anyone who has commented on the PR. Most of our reviewers are volunteers and sometimes things fall through the cracks.

You can also join uson gitter for real-time discussion.

For details on testing, writing docs, and our review process, please seethe developer guide

We strive to be a welcoming and open project. Please follow ourCode of Conduct.

@tacaswelltacaswell added this to thev3.6.0 milestoneApr 13, 2022
@oscargusoscargus added the status: needs workflow approvalFor PRs from new contributors, from which GitHub blocks workflows by default. labelApr 13, 2022
@yumasheta
Copy link
ContributorAuthor

I don't have tests for inhomogeneously spaced boundaries. Shall I include some?

@tacaswell
Copy link
Member

I don't have tests for inhomogeneously spaced boundaries. Shall I include some?

On one hand you could argue that more tests are always better (because tests are better than on tests), but that fails in the same way that "if 1 apple is good, then N+1 apples is always better!" fails. More tests take more time to run, more places that things unrelated to the test can go wrong etc.

So, the judgement is if the non-uniform test will exercise something important that is not exercised in the uniform case?

@yumasheta
Copy link
ContributorAuthor

Not that I can think of.

# map range -1..1 to 0..256 in 0.01 steps
fig, ax = plt.subplots()
fig.suptitle("-1..1 to 0..256 in 0.001")
cmap = cm.get_cmap('RdBu_r', 2000)
Copy link
Member

@oscargusoscargusApr 21, 2022
edited
Loading

Choose a reason for hiding this comment

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

Looks like you are not using this variable? (And therefore not the cm import.) Nor the similar in the previous section.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

You are right. Fixed it! (Though, I think resampling the colormap to match the number of regions only makes a difference when viewing the plots.)

Copy link
Member

Choose a reason for hiding this comment

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

I also think so, so the alternate fix of just removing thecmap may have been preferred. But now these tests will also serve as examples, so I am not strongly in favor in removing it.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Me too, that's why I left them in. The tests are more complete this way and produce expected results if anyone decided to look at the plots, or took my tests as examples.

@yumashetayumasheta requested a review fromoscargusMay 7, 2022 11:48
Copy link
Member

@oscargusoscargus left a comment

Choose a reason for hiding this comment

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

I think the fix looks good!

One could possibly consider simplifying/shortening the test code a bit:

  • Direct creation of test data (instead of assigning separate elements)
  • Removing cmap (as discussed earlier)
  • Skipping figure titles
  • No need toclose as next plot is created in a newfig

However, apart from the first point, the rest are useful when running the code in a terminal. Not sure what the consensus is on this (although I guess no one would object if they weren't there).

yumasheta reacted with thumbs up emoji
@oscargusoscargus added topic: collections and mappables and removed status: needs workflow approvalFor PRs from new contributors, from which GitHub blocks workflows by default. labelsMay 17, 2022
@jklymak
Copy link
Member

Is there some reason to not just use this approximation to make BoundaryNorm (non-uniquely) invertible?

@jklymakjklymak modified the milestones:v3.6.0,v3.5.3May 22, 2022
@jklymak
Copy link
Member

This actually is a regression and should be fixed ASAP...

@yumasheta
Copy link
ContributorAuthor

Is there some reason to not just use this approximation to make BoundaryNorm (non-uniquely) invertible?

My PR doesn't include this functionality. It depends on the data being available and works around the inversion by using argmin.
If I'm not mistaken...

@@ -372,3 +374,117 @@ class MyArtist4(MyArtist3):
pass

assert MyArtist4.set is MyArtist3.set


def test_format_cursor_data_BoundaryNorm():
Copy link
Member

Choose a reason for hiding this comment

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

Why are you testing this intest_artist? are there other format tests in test_artist?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Because my changes are inartist.py. What's a better place?

Copy link
Member

Choose a reason for hiding this comment

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

... fair!

norm = mcolors.BoundaryNorm(np.linspace(-1, 1, 20), 256)
img = ax.imshow(X, cmap='RdBu_r', norm=norm)
for v in X.flat:
label = "[{:-#.{}g}]".format(v, cbook._g_sig_digits(v, 0.1))
Copy link
Member

Choose a reason for hiding this comment

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

This test just tests that the code is called, not that the resulting labels are correct. Please consider writing out explicitly what the labels should be and comparing those.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Ok, but I do this fixture for all the tests. Yes, I do in principle only test, if thecbook._g_sig_digits is called. But the important check is, if it is called with the correct arguments. My PR only prepares the values for the arguments.

Instead of comparing the output ofArtist.format_cursor_data I could also just test if thedelta argument is correct. But as it is now, I also test if the output for the cursor data is actually generated correctly. I do compare with a predefined label, though not written out explicitly but generated via a customcbook call.

So I don't know what to do? Do you want me to just replace l. 398 with the verbatim output of the format call?

Copy link
Member

Choose a reason for hiding this comment

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

So I don't know what to do? Do you want me to just replace l. 398 with the verbatim output of the format call?

Yes, I think so. In general it is bad for the tests to include private methods, though that is a rule meant to be broken...

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Agreed, it is more understandable that way. But I left the original lines with thecbook as comments.

@jklymakjklymak marked this pull request as draftJune 23, 2022 08:26
@jklymak
Copy link
Member

the fix looks good. The tests are circular, and I'm not sure ware in correct place. Moved to draft, feel free to mark "ready" when addressed Thanks!

@yumashetayumasheta marked this pull request as ready for reviewJune 23, 2022 11:54
@jklymak
Copy link
Member

I'll merge once CI is done - feel free to squash, or we will squash for you at merge....

yumasheta reacted with hooray emoji

@jklymakjklymak merged commit6e5a541 intomatplotlib:mainJun 23, 2022
@jklymak
Copy link
Member

Thanks@yumasheta !

yumasheta reacted with heart emoji

meeseeksmachine pushed a commit to meeseeksmachine/matplotlib that referenced this pull requestJun 23, 2022
tacaswell added a commit that referenced this pull requestJun 23, 2022
…835-on-v3.5.xBackport PR#22835 on branch v3.5.x (Fix BoundaryNorm cursor data output)
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@tacaswelltacaswelltacaswell left review comments

@github-actionsgithub-actions[bot]github-actions[bot] left review comments

@jklymakjklymakjklymak approved these changes

@oscargusoscargusoscargus approved these changes

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

Successfully merging this pull request may close these issues.

[Bug]: scalar mappable format_cursor_data crashes on BoundarNorm
4 participants
@yumasheta@tacaswell@jklymak@oscargus

[8]ページ先頭

©2009-2025 Movatter.jp