-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Do not add padding to 3D axis limits when limits are manually set #25272
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
Conversation
Although I think that this is really how it should be, the question is if we can just enforce it or if there should be a deprecation path? Better ping in @timhoffm directly... |
56f5c0e
to
eb13ba8
Compare
This is changing intended behavior in some of the tests so some tweaking to do, but should be enough here right now to get an idea. |
Talked about this in the dev call today, consensus was to make the new behavior default without deprecation, but add an rc_param to switch back to current behavior. |
ba17fca
to
164a811
Compare
164a811
to
9ed0c5b
Compare
3200e54
to
2239207
Compare
40fc8f0
to
1c04693
Compare
Well, it looks like the floating point theory is likely correct, because the tests are all passing on my machine, and the different CI platforms are having different tests throw image comparison errors. What's the proper way to handle this? Loosen the image comparison tolerance? I'm not sure how to examine the test images from the different CI environments if I can't recreate the issue locally. |
00f03ca
to
43f7d59
Compare
The ideal way is to add platform-specific margins, like: matplotlib/lib/matplotlib/tests/test_lines.py Lines 187 to 189 in e7fd79f
I think one way to make it at least slightly better is to pre-compute the constants. In this way one error source is removed and the code will execute slightly faster. Always possible to use a comment to illustrate where it comes from. |
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.
Most of the constants should be pre-computed I think.
Doc-strings should typically have a single-sentence/line description (hence, the need for an empty line after).
A change note is required for the new rcParam
I think the purpose of the PR is for sure worthwhile, but I do not know enough to have any real comments on the implentation.
b55d12c
to
978889b
Compare
Thank you for the thorough review @oscargus! To give some context for where these constants are coming from, the original behavior when generating the view limits for 3d plots was fairly broken. There was always 1/48 of the axis range added to either side of the axis bounds when drawing the axes, however this extra "view margin" was purely visual. The calculations for the zoom level for the plot, which grid/tick lines to show, and several other spots in the code all used the non-padded axis limits for their calculation. So, when I converted the backed to use the actual axis limits everywhere, this required putting in a lot of scale factors to keep the visual appearance ( |
978889b
to
415763e
Compare
OK, can we mention that in the comments? It currently says something like "to match mpl3.7 appearance", so it can say "to match mpl3.7 appearance that added 1/48 padding". Also feel free to put a longer explanation in the commit message. |
6b38c5e
to
dfdc014
Compare
fe42617
to
24254de
Compare
Thanks! Rebased/squashed, and added a lot more detail to the comments on scale factors. @QuLogic do those address your concerns? |
Fix remaining large image diffs Fix remaining large image diffs Fix the rest of the tests Fix docs error Code review updates Code review updates Fix docs error One more constant Tweaks Keep fixing CI errors Docstrings Update baseline images More test images Images Test new scaling factor Test new scaling factor Test for exact limits Cleanup Tests Update doc/users/next_whats_new/3d_axis_limits.rst Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com> rebase fixes Apply suggestions from code review Co-authored-by: Oscar Gustafsson <oscar.gustafsson@gmail.com> Code review cleanup Merge conflicts and better comments Merge conflicts and better comments
24254de
to
f1141d1
Compare
f60f5a0
to
0da1b6c
Compare
Bump on merging this now that 3.8.0 is out |
@scottshambaugh Thanks! |
Unclear to me why this didn't happen for this PR, but references to
It looks like the warning is that it can't find them at all, rather than that it e.g. sees both Sphinx version is different (7.2.4 here, 7.2.6 on main), though only as patch releases, and nothing obviously related in release notes.
|
Attempt to fix doc build failure introduced with matplotlib#25272. I suspect this is sphinx scoping: matplotlib#25272 reused methods like `Axes.set_xbounds` to generate documentation for Axes3D. However, a see also of invert_xaxis only searches within the same module (or class), and invert_xaxis is not documented for Axes3D. This PR broadens the search scope by using the leading dot. An alternative may be to attempt to explicitly document the missing methods for Axes3D.
Attempt to fix doc build failure introduced with matplotlib#25272. I suspect this is sphinx scoping: matplotlib#25272 reused methods like `Axes.set_xbounds` to generate documentation for Axes3D. However, a see also of invert_xaxis only searches within the same module (or class), and invert_xaxis is not documented for Axes3D. This PR attempt to explicitly document the missing methods for Axes3D.
PR Summary
Closes #18052
Before:

After (exact limits for x and y, z retains default padded limits):

There are a ton of test image changes, gonna be a hefty commit.PR Checklist
Documentation and Tests
pytest
passes)Release Notes
.. versionadded::
directive in the docstring and documented indoc/users/next_whats_new/
.. versionchanged::
directive in the docstring and documented indoc/api/next_api_changes/
next_whats_new/README.rst
ornext_api_changes/README.rst