Skip to content

Turn autoscale into a contextmanager. #5538

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 4 commits into from

Conversation

anntzer
Copy link
Contributor

@anntzer anntzer commented Nov 21, 2015

See #5510.

Also clarify a bit the implementation of autoscale, and fix an issue about the
lack of effect of set_autoscalez_on for 3D axes, which was previously visible
by running::

from pylab import *
from mpl_toolkits import mplot3d

gcf().add_subplot(111, projection="3d")
plot([0, 1], [0, 1], [0, 1])
gca().set_autoscalex_on(False)
gca().set_autoscalez_on(False) # has no effect
plot([2, 3], [2, 3], [2, 3])
show()


or::

@axes.autoscale(enable)
Copy link
Member

Choose a reason for hiding this comment

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

I would not suggest this in the documentation as this binds the definition of this function to a specific instance.

@tacaswell
Copy link
Member

This will need documentation in both whats_new and api_changes I think.

@tacaswell
Copy link
Member

Can you also add a test of the context manager?

@tacaswell tacaswell added this to the proposed next point release (2.1) milestone Nov 22, 2015
@anntzer
Copy link
Contributor Author

anntzer commented Nov 22, 2015

A quick grep suggests that there isn't even any testing done for the regular autoscale function (or am I missing something?). If someone writes one I could build on top of it...

@tacaswell
Copy link
Member

Then you can kill two birds with one stone!

This doesn't need to be image tests, you can just check what the limits are.

On Sun, Nov 22, 2015, 17:52 Antony Lee notifications@github.com wrote:

A quick grep suggests that there isn't even any testing done for the
regular autoscale function (or am I missing something?). If someone
writes one I could build on top of it...


Reply to this email directly or view it on GitHub
#5538 (comment)
.

@anntzer
Copy link
Contributor Author

anntzer commented Nov 23, 2015

Does this look good enough?

@mdboom
Copy link
Member

mdboom commented Nov 23, 2015

👍 from me, but I agree with @tacaswell that the decorator approach, being tied to a specific Axes object, shouldn't be recommended.

Looks like this needs a rebase.

See matplotlib#5510.

Also clarify a bit the implementation of autoscale, and fix an issue about the
lack of effect of set_autoscalez_on for 3D axes, which was previously visible
by running::

    from pylab import *
    from mpl_toolkits import mplot3d

    gcf().add_subplot(111, projection="3d")
    plot([0, 1], [0, 1], [0, 1])
    gca().set_autoscalex_on(False)
    gca().set_autoscalez_on(False) # has no effect
    plot([2, 3], [2, 3], [2, 3])
    show()
@anntzer
Copy link
Contributor Author

anntzer commented Nov 23, 2015

Done.

try:
yield
finally:
self._autoscaleXon, self._autoscaleYon = orig_autoscale
Copy link
Member

Choose a reason for hiding this comment

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

should we mark the axes object as stale?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

(I have no idea of what you're talking about so I'll leave the discussion to the specialists.)

Copy link
Member

Choose a reason for hiding this comment

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

I don't think this needs to set stale because changing this internal state does not invalidate the drawn figure (that is the next call to draw will not be different)....unless I am miss understanding how this works.

@tacaswell
Copy link
Member

For future reference, please see the directions in the readme at https://github.com/matplotlib/matplotlib/tree/master/doc/users/whats_new . By putting the whats_new / api-changes into separate files we avoid a lot of un-needed rebases.

if axis in ['y', 'both']:
self._autoscaleYon = bool(enable)
scaley = self._autoscaleYon
self.autoscale_view(tight=tight, scalex=scalex, scaley=scaley)
self.autoscale_view(
Copy link
Member

Choose a reason for hiding this comment

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

This does not behave the same if enable is None. Previously, ax.autoscale(None) would autoscale both axis, but leave the _autoscale*on state unchanged, now it scale the axis dependent on the current values of _autoscale*on.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

OK, so I misunderstood the code (I never used autoscale(None) so I had no idea what it did). I still don't understand the actual behavior: autoscaling (in autoscale_view) is protected by the conditional if scalex and self._autoscaleXon, so I thought that just passing scalex=True would not perform an autoscale as long as self._autoscaleXon is False.
Where did I go wrong?

Copy link
Member

Choose a reason for hiding this comment

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

I was just reading this code locally and sorting through what inputs are going to the autoscale_view, you are correct this does not actually change the behaviour. Sorry for the noise.

@anntzer
Copy link
Contributor Author

anntzer commented Apr 7, 2016

I don't really know what to do with this PR: on the one hand it's in a working state, on the other hand I feel like there should be a better model for autoscaling: rather than being a switch on the axes, I'd rather it be a switch on the artists themselves, marking, for each artist, whether it should be considered for autoscaling computations. This would allow dynamically adding artists in whatever order is convenient while maintaining fine control over autoscaling.

Thoughts?

@tacaswell
Copy link
Member

There is some recent precedence for that sort of thing as artist can report if they want tight bounds or note in the auto scaling. Just not participating seems like a reasonable option to add.

@anntzer
Copy link
Contributor Author

anntzer commented Apr 7, 2016

Uh, through what mechanism?

Also, looking at it again, it's going to be a bit awkward to keep backcompatibility, as usual... This is how I envision it:
There's a field participates_in_autoscale in each artist, defaulting to True. When relim is called, only artists that want to participate are taken into account. Calling autoscale(False) switches the default value to False. The problem is that from a strict backcompatibility POV, calling autoscale(True) should not only revert the default value back to True, but also switch the value for all other artists back to True too. While this is technically not too hard (e.g. there could be a third value, None, which just means "use the default value"), this would kind of defeat the purpose of it. More likely, you need either to change the behavior of autoscale(True), or deprecate it and have another switcher which simply sets the default value of the flag without modifying its value for already created artists.
Thoughts?

@tacaswell
Copy link
Member

See #5583 for the margin machinery.

@anntzer
Copy link
Contributor Author

anntzer commented Apr 7, 2016

OK, so I guess I should replace the values of the margin attribute by a tristate "ignore/no_margin/want_margin"? Also I feel like this attribute should be private...
Any thoughts re. backwards compatibility?

Changes in 2.1.0
================

Code changes
Copy link
Member

Choose a reason for hiding this comment

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

Can you put these is a file in api_changes/*.rst. This helps to prevent the sort of conflicts this branch has.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd rather close this PR and make margin a tristate as discussed above. In fact, making autoscale a contextmanager is a bit misleading given that at the exit of the contextmanager (assuming it temporarily disabled autoscaling), all the artists, including those created while the cm was active, will participate in the next autoscaling... which defeats the purpose of the cm IMO. Thoughts?

The fix for z autoscaling should go in its own PR.

Copy link
Member

Choose a reason for hiding this comment

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

@anntzer That sounds like a good plan to me.

Wish we were 3 only and could use enums 😞

Copy link
Contributor Author

@anntzer anntzer Sep 24, 2016

Choose a reason for hiding this comment

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

In this case I think the best is to use strings everywhere (IMO the problem of using, say, True, False and a third value is that it is too easy to accidentally test for the boolean value and forget about the third possibility). Say "default" (current True), "remove" (current False) and "ignore"?

attn @mdboom as the author of #5583.

@anntzer
Copy link
Contributor Author

anntzer commented Apr 16, 2017

This can't really be made to work with the current machinery. What would be needed is to union the bboxes at draw time, while checking for a hypothetical "participates_in_autoscale" flag. See #7413 (which is not strictly needed, but related).

@anntzer anntzer closed this Apr 16, 2017
@anntzer anntzer deleted the autoscale-cm branch June 23, 2017 09:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants