Skip to content

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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

Add finer-grain control to Axes.ignore_existing_data_limits #18771

wants to merge 1 commit into from

Conversation

l-johnston
Copy link
Contributor

@l-johnston l-johnston commented Oct 19, 2020

PR Summary

Solving #7742 requires finer-grain control over which data limits to update during the call to update_path_extents. A previous attempt at solving this problem, PR #8210, simply tried to keep ignore_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 (and pytest passes).
  • Is Flake 8 compliant (run flake8 on changed files to check).
  • New features are documented, with examples if plot related.
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).
  • Conforms to Matplotlib style conventions (install flake8-docstrings and pydocstyle<4 and run flake8 --docstring-convention=all).
  • New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).

@tacaswell
Copy link
Member

I think this is going the right direction, but we need to propagate the documentation changes back to bbox and update_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 the case 1: code not the case 0: code (as currently any positive number is treated as "ignore")?

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

@tacaswell tacaswell added this to the v3.4.0 milestone Oct 22, 2020
@anntzer
Copy link
Contributor

anntzer commented Oct 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".

@tacaswell
Copy link
Member

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 limits only in the meaningful direction.

@anntzer
Copy link
Contributor

anntzer commented Oct 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" transData in that direction (#13642 (review), #17017 (comment)).

@l-johnston
Copy link
Contributor Author

@anntzer I have an alternative solution that avoids ignore_existing_data_limits pushed to a new branch. Should I close this PR and open a new one?

@anntzer
Copy link
Contributor

anntzer commented Oct 23, 2020

I don't know how easy the solution I proposed would be to implement, but yes, you can open a separate PR for it.

@l-johnston l-johnston closed this Oct 23, 2020
@QuLogic QuLogic removed this from the v3.4.0 milestone Mar 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants