NotificationsYou must be signed in to change notification settings
Fork7.9k
Star21.3k

Add finer-grain control to Axes.ignore_existing_data_limits#18771

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

Jump to bottom

Closed

l-johnston wants to merge1 commit intomatplotlib:masterfroml-johnston:issue_7742

Closed

Add finer-grain control to Axes.ignore_existing_data_limits#18771

l-johnston wants to merge1 commit intomatplotlib:masterfroml-johnston:issue_7742

Conversation

Copy link

Contributor

l-johnston commentedOct 19, 2020•
edited
Loading

PR Summary

Solving#7742 requires finer-grain control over which data limits to update during the call toupdate_path_extents. A previous attempt at solving this problem, PR#8210, simply tried to keepignore_existing_data_limits=True when plotting spans, but this approach fails when adding a second span.

Adding this feature probably impacts#18401 and#17106.

PR Checklist

Has pytest style unit tests (andpytest passes).
IsFlake 8 compliant (runflake8 on changed files to check).
New features are documented, with examples if plot related.
Documentation is sphinx and numpydoc compliant (the docs shouldbuild without error).
Conforms to Matplotlib style conventions (installflake8-docstrings andpydocstyle<4 and runflake8 --docstring-convention=all).
New features have an entry indoc/users/next_whats_new/ (follow instructions in README.rst there).
API changes documented indoc/api/next_api_changes/ (follow instructions in README.rst there).

Add finer-grain control to Axes.ignore_existing_data_limits

9931011

Copy link

Member

tacaswell commentedOct 22, 2020

I think this is going the right direction, but we need to propagate the documentation changes back to bbox andupdate_path_extents.

I would also be inclined to make the default behavior in the switch "fail". If we did keep a non-erroring default state shouldn't it be thecase 1: code not thecase 0: code (as currently any positive number is treated as "ignore")?

Is it worth looking into anEnum for this on the Python side?

tacaswell added this to thev3.4.0 milestone

Oct 22, 2020

Copy link

Contributor

anntzer commentedOct 22, 2020

I am not convinced that adding more epicycles is the way to go here. See writeup at#17106 (comment); the short version is basically "axes currently start with a datalim of (0, 1)/(0, 1) which is marked as 'ignore' so that later plots override it, but instead they should just start with a completely empty datalim and we should just use locator.nonsingular to expand it if needed at autoscaling time".

Copy link

Member

tacaswell commentedOct 22, 2020

I thought this was a problem with spans even after we had added a bunch of artists and did have real limits everywhere.

We want to be able to update the limitsonly in the meaningful direction.

Copy link

Contributor

anntzer commentedOct 22, 2020

But (I think) that's a separate point, which should not be controlled by a flag on the bbox, but rather by checking whether the artist transform "contains" transDatain that direction (#13642 (review),#17017 (comment)).