should set_xlim turn off x autoscaling?

The present behavior of set_xlim and set_ylim can be surprising because making the values stick for subsequent plotting in the same axes requires manually calling set_autoscalex_on(False) etc. It would seem more logical if set_xlim itself included the call to turn autoscalex off--isn't that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some existing user code.

What are people's thoughts on this? Should the change made? If so, do it abruptly, right now, as part of version 1.0? Or phase it in with a temporary kwarg and/or rcparam? It would be nice to avoid all that complexity, but may be we can't, except by leaving everything as it is now.

Eric

Seems like a reasonable request to me. When I use xlim to specify the
axes in a plot session, I tend to use it multiple times. Therefore
this default behaviour would seem reasonable.

···

On Sun, Jun 27, 2010 at 4:40 PM, Eric Firing <efiring@...229...> wrote:

The present behavior of set_xlim and set_ylim can be surprising because
making the values stick for subsequent plotting in the same axes
requires manually calling set_autoscalex_on(False) etc. It would seem
more logical if set_xlim itself included the call to turn autoscalex
off--isn't that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some
existing user code.

What are people's thoughts on this? Should the change made? If so, do
it abruptly, right now, as part of version 1.0? Or phase it in with a
temporary kwarg and/or rcparam? It would be nice to avoid all that
complexity, but may be we can't, except by leaving everything as it is now.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I agree, while most of the time I call set_xlim() after all plotting is finished, there are some cases where I call it before subsequent plot calls, and this is a little nutty. I wonder how this change in behavior would impact basemap which always seemed to have to code around this issue?

Ben Root

···

On Sun, Jun 27, 2010 at 7:39 PM, Paul Barrett <pebarrett@…149…> wrote:

Seems like a reasonable request to me. When I use xlim to specify the

axes in a plot session, I tend to use it multiple times. Therefore

this default behaviour would seem reasonable.

On Sun, Jun 27, 2010 at 4:40 PM, Eric Firing <efiring@…229…> wrote:

The present behavior of set_xlim and set_ylim can be surprising because

making the values stick for subsequent plotting in the same axes

requires manually calling set_autoscalex_on(False) etc. It would seem

more logical if set_xlim itself included the call to turn autoscalex

off–isn’t that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some

existing user code.

What are people’s thoughts on this? Should the change made? If so, do

it abruptly, right now, as part of version 1.0? Or phase it in with a

temporary kwarg and/or rcparam? It would be nice to avoid all that

complexity, but may be we can’t, except by leaving everything as it is now.

Eric


This SF.net email is sponsored by Sprint

What will you do first with EVO, the first 4G phone?

Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


This SF.net email is sponsored by Sprint

What will you do first with EVO, the first 4G phone?

Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Rather than changing the existing xlim, it would be better to create a new
command xlim2 with the desired behaviour (if needed).

efiring wrote:

···

The present behavior of set_xlim and set_ylim can be surprising because
making the values stick for subsequent plotting in the same axes
requires manually calling set_autoscalex_on(False) etc. It would seem
more logical if set_xlim itself included the call to turn autoscalex
off--isn't that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some
existing user code.

What are people's thoughts on this? Should the change made? If so, do
it abruptly, right now, as part of version 1.0? Or phase it in with a
temporary kwarg and/or rcparam? It would be nice to avoid all that
complexity, but may be we can't, except by leaving everything as it is
now.

Eric


View this message in context: http://old.nabble.com/should-set_xlim-turn-off-x-autoscaling--tp29007843p29016365.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Rather than changing the existing xlim, it would be better to create a new
command xlim2 with the desired behaviour (if needed).

Why, specifically in this case?

I'm somewhat reluctant to see that proliferation of methods and functions.

Is there actually a reasonable use case for the present behavior--is it advantageous under some circumstances? What sort of code is likely to depend on it?

Eric

···

On 06/28/2010 04:42 PM, butterw wrote:

efiring wrote:

The present behavior of set_xlim and set_ylim can be surprising because
making the values stick for subsequent plotting in the same axes
requires manually calling set_autoscalex_on(False) etc. It would seem
more logical if set_xlim itself included the call to turn autoscalex
off--isn't that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some
existing user code.

What are people's thoughts on this? Should the change made? If so, do
it abruptly, right now, as part of version 1.0? Or phase it in with a
temporary kwarg and/or rcparam? It would be nice to avoid all that
complexity, but may be we can't, except by leaving everything as it is
now.

Eric

Rather than changing the existing xlim, it would be better to create a new
command xlim2 with the desired behaviour (if needed).

Why, specifically in this case?

I'm somewhat reluctant to see that proliferation of methods and functions.

Is there actually a reasonable use case for the present behavior--is it
advantageous under some circumstances? What sort of code is likely to
depend on it?

The present behaviour bites me every time. I keep forgetting that the
xlim has to be last and plotting afterward. So I'd prefer this change.
But let me be the devil's advocate.

Suppose I want to plot a number of different things, with autoscaling
so that the plot fits them all. This won't change. Now suppose I want
the "autoscaling" to actually include, for each plotting action,
explicitly set x and y limits. This still won't change. But if I want
to omit some of the x and y limits, then the behaviour might change.
That is, if I have some framework designed to plot several things in a
row on the same plot, and if that framework sometimes calls xlim/ylim
when new things are added, but not always, then I might find this
change an unpleasant surprise.

I'd be inclined to handle this with a warning - if possible, one that
was triggered only when drawing something that would have triggered a
rescaling but now no longer does. If that's infeasible, my inclination
would be to just change it. But I won't be the one who's stuck dealing
with a stream of puzzled users...

Anne

···

On 28 June 2010 23:11, Eric Firing <efiring@...229...> wrote:

On 06/28/2010 04:42 PM, butterw wrote:

Eric

efiring wrote:

The present behavior of set_xlim and set_ylim can be surprising because
making the values stick for subsequent plotting in the same axes
requires manually calling set_autoscalex_on(False) etc. It would seem
more logical if set_xlim itself included the call to turn autoscalex
off--isn't that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some
existing user code.

What are people's thoughts on this? Should the change made? If so, do
it abruptly, right now, as part of version 1.0? Or phase it in with a
temporary kwarg and/or rcparam? It would be nice to avoid all that
complexity, but may be we can't, except by leaving everything as it is
now.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I just thought of a possible interaction issue that might have to be sorted out. If we want a .set_xlim() to firmly establish the data limits, what about a future (or previous) call to ax.set_aspect(‘equal’, ‘datalim’)? This causes the data limits to change within the figure box.

Ben Root

···

On Mon, Jun 28, 2010 at 10:48 PM, Anne Archibald <aarchiba@…824…> wrote:

On 28 June 2010 23:11, Eric Firing <efiring@…229…> wrote:

On 06/28/2010 04:42 PM, butterw wrote:

Rather than changing the existing xlim, it would be better to create a new

command xlim2 with the desired behaviour (if needed).

Why, specifically in this case?

I’m somewhat reluctant to see that proliferation of methods and functions.

Is there actually a reasonable use case for the present behavior–is it

advantageous under some circumstances? What sort of code is likely to

depend on it?

The present behaviour bites me every time. I keep forgetting that the

xlim has to be last and plotting afterward. So I’d prefer this change.

But let me be the devil’s advocate.

Suppose I want to plot a number of different things, with autoscaling

so that the plot fits them all. This won’t change. Now suppose I want

the “autoscaling” to actually include, for each plotting action,

explicitly set x and y limits. This still won’t change. But if I want

to omit some of the x and y limits, then the behaviour might change.

That is, if I have some framework designed to plot several things in a

row on the same plot, and if that framework sometimes calls xlim/ylim

when new things are added, but not always, then I might find this

change an unpleasant surprise.

I’d be inclined to handle this with a warning - if possible, one that

was triggered only when drawing something that would have triggered a

rescaling but now no longer does. If that’s infeasible, my inclination

would be to just change it. But I won’t be the one who’s stuck dealing

with a stream of puzzled users…

Anne

Eric

efiring wrote:

The present behavior of set_xlim and set_ylim can be surprising because

making the values stick for subsequent plotting in the same axes

requires manually calling set_autoscalex_on(False) etc. It would seem

more logical if set_xlim itself included the call to turn autoscalex

off–isn’t that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some

existing user code.

What are people’s thoughts on this? Should the change made? If so, do

it abruptly, right now, as part of version 1.0? Or phase it in with a

temporary kwarg and/or rcparam? It would be nice to avoid all that

complexity, but may be we can’t, except by leaving everything as it is

now.

Eric


This SF.net email is sponsored by Sprint

What will you do first with EVO, the first 4G phone?

Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


This SF.net email is sponsored by Sprint

What will you do first with EVO, the first 4G phone?

Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

My understanding is that the proposed change will break at least some
existing code, hence my proposal to go the safer route.

Also I'm unconvinced by the justification for the change :
xlim and autoscalex_on are independant attributes, why then should setting
xlim have the side effect of turning autoscalex off ? This is not consistent
with how the API works. If I really wanted autoscalex off, I would have
specified it.

To sum things up:
Adding an argument to set_xlim to allow autoscale to be turned off in the
same step would be a good idea. But it shouldn't suddenly become the default
behaviour.

efiring wrote:

···

On 06/28/2010 04:42 PM, butterw wrote:

Rather than changing the existing xlim, it would be better to create a
new
command xlim2 with the desired behaviour (if needed).

Why, specifically in this case?

I'm somewhat reluctant to see that proliferation of methods and functions.

Is there actually a reasonable use case for the present behavior--is it
advantageous under some circumstances? What sort of code is likely to
depend on it?

Eric

efiring wrote:

The present behavior of set_xlim and set_ylim can be surprising because
making the values stick for subsequent plotting in the same axes
requires manually calling set_autoscalex_on(False) etc. It would seem
more logical if set_xlim itself included the call to turn autoscalex
off--isn't that what a user would almost always want and expect?

Rectifying this would constitute a significant change affecting some
existing user code.

What are people's thoughts on this? Should the change made? If so, do
it abruptly, right now, as part of version 1.0? Or phase it in with a
temporary kwarg and/or rcparam? It would be nice to avoid all that
complexity, but may be we can't, except by leaving everything as it is
now.

Eric

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


View this message in context: http://old.nabble.com/should-set_xlim-turn-off-x-autoscaling--tp29007843p29029292.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

I just thought of a possible interaction issue that might have to be
sorted out. If we want a .set_xlim() to firmly establish the data
limits, what about a future (or previous) call to
ax.set_aspect('equal', 'datalim')? This causes the data limits to
change within the figure box.

True, but I don't see set_xlim as absolutely fixing the limits for all
time, just as turning off autoscaling. Regardless of the state of
autoscaling, apply_aspect will override the limits if it needs to; the
original limits, whether set manually or via autoscaling, are treated as
lower bounds.

Eric

···

On Tue, 2010-06-29 at 15:32 -0500, Benjamin Root wrote:

Ben Root

On Mon, Jun 28, 2010 at 10:48 PM, Anne Archibald > <aarchiba@...824...> wrote:
        On 28 June 2010 23:11, Eric Firing <efiring@...229...> wrote:
        > On 06/28/2010 04:42 PM, butterw wrote:
        >>
        >> Rather than changing the existing xlim, it would be better
        to create a new
        >> command xlim2 with the desired behaviour (if needed).
        >
        > Why, specifically in this case?
        >
        > I'm somewhat reluctant to see that proliferation of methods
        and functions.
        >
        > Is there actually a reasonable use case for the present
        behavior--is it
        > advantageous under some circumstances? What sort of code is
        likely to
        > depend on it?
        
        The present behaviour bites me every time. I keep forgetting
        that the
        xlim has to be last and plotting afterward. So I'd prefer this
        change.
        But let me be the devil's advocate.
        
        Suppose I want to plot a number of different things, with
        autoscaling
        so that the plot fits them all. This won't change. Now suppose
        I want
        the "autoscaling" to actually include, for each plotting
        action,
        explicitly set x and y limits. This still won't change. But if
        I want
        to omit some of the x and y limits, then the behaviour might
        change.
        That is, if I have some framework designed to plot several
        things in a
        row on the same plot, and if that framework sometimes calls
        xlim/ylim
        when new things are added, but not always, then I might find
        this
        change an unpleasant surprise.
        
        I'd be inclined to handle this with a warning - if possible,
        one that
        was triggered only when drawing something that would have
        triggered a
        rescaling but now no longer does. If that's infeasible, my
        inclination
        would be to just change it. But I won't be the one who's stuck
        dealing
        with a stream of puzzled users...
        
        Anne
        
        > Eric
        >
        >>
        >>
        >>
        >> efiring wrote:
        >>>
        >>> The present behavior of set_xlim and set_ylim can be
        surprising because
        >>> making the values stick for subsequent plotting in the
        same axes
        >>> requires manually calling set_autoscalex_on(False) etc.
         It would seem
        >>> more logical if set_xlim itself included the call to turn
        autoscalex
        >>> off--isn't that what a user would almost always want and
        expect?
        >>>
        >>> Rectifying this would constitute a significant change
        affecting some
        >>> existing user code.
        >>>
        >>> What are people's thoughts on this? Should the change
        made? If so, do
        >>> it abruptly, right now, as part of version 1.0? Or phase
        it in with a
        >>> temporary kwarg and/or rcparam? It would be nice to avoid
        all that
        >>> complexity, but may be we can't, except by leaving
        everything as it is
        >>> now.
        >>>
        >>> Eric
        >>>
        >>
        >
        >
        >
        ------------------------------------------------------------------------------
        > This SF.net email is sponsored by Sprint
        > What will you do first with EVO, the first 4G phone?
        > Visit sprint.com/first --
        http://p.sf.net/sfu/sprint-com-first
        > _______________________________________________
        > Matplotlib-devel mailing list
        > Matplotlib-devel@lists.sourceforge.net
        >
        https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
        >
        
        ------------------------------------------------------------------------------
        This SF.net email is sponsored by Sprint
        What will you do first with EVO, the first 4G phone?
        Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
        _______________________________________________
        Matplotlib-devel mailing list
        Matplotlib-devel@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
        
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

My understanding is that the proposed change will break at least some
existing code, hence my proposal to go the safer route.

On what is that understanding based? Any actual examples or use cases?

I think the only such cases would be interactive scripts. One can
imagine a script in which a plot is made, the user views it, perhaps
uses a gui to change the limits, then presses a button to plot the next
data set on top of the first, expecting that it will again autoscale,
and so forth. Maybe this is sufficient justification for leaving the
present version alone. That is what I am trying to find out. In
addition, the change would require scanning the internal mpl code to see
whether there are uses of set_xlim that would have to be changed.

Also I'm unconvinced by the justification for the change :
xlim and autoscalex_on are independant attributes, why then should setting

They are not independent, they are potentially in conflict--two
mechanisms fighting for control of the axis.

xlim have the side effect of turning autoscalex off ? This is not consistent
with how the API works. If I really wanted autoscalex off, I would have
specified it.

The idea of having interactive plotting commands is to make the
interaction easy and natural. When you call set_xlim interactively, it
is because that is what you want the limits to be. At least that point
of view has been expressed several times on the lists. I have yet to
hear someone say, "I rely on the present behavior". In scripts, when
there is no interactive scenario such as I described in the previous
paragraph, the problem with the present behavior is that it means
set_xlim has no effect at all if followed by a plot command unless one
has disabled autoscaling either via a kwarg in the plot command, or via
ax.set_autoscalex_on(False). The latter is just plain ugly, to my eye.

To sum things up:
Adding an argument to set_xlim to allow autoscale to be turned off in the
same step would be a good idea. But it shouldn't suddenly become the default
behaviour.

You may well be right about this. In any case, I suspect no change will
occur prior to the 1.0 release.

Additional perspective: the behavior of Matlab's xlim is as I have
proposed, not as mpl xlim presently works. I don't believe in following
Matlab slavishly--sometimes we can make better choices than Matlab
has--but I think that this is a case where Matlab got it right and we
did not, the first time around. This may be because the _autoscalex and
_autoscaley attributes were added to the mpl Axes long after set_xlim.

Eric

···

On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:

efiring wrote:
>
> On 06/28/2010 04:42 PM, butterw wrote:
>>
>> Rather than changing the existing xlim, it would be better to create a
>> new
>> command xlim2 with the desired behaviour (if needed).
>
> Why, specifically in this case?
>
> I'm somewhat reluctant to see that proliferation of methods and functions.
>
> Is there actually a reasonable use case for the present behavior--is it
> advantageous under some circumstances? What sort of code is likely to
> depend on it?
>
> Eric
>
>>
>>
>>
>> efiring wrote:
>>>
>>> The present behavior of set_xlim and set_ylim can be surprising because
>>> making the values stick for subsequent plotting in the same axes
>>> requires manually calling set_autoscalex_on(False) etc. It would seem
>>> more logical if set_xlim itself included the call to turn autoscalex
>>> off--isn't that what a user would almost always want and expect?
>>>
>>> Rectifying this would constitute a significant change affecting some
>>> existing user code.
>>>
>>> What are people's thoughts on this? Should the change made? If so, do
>>> it abruptly, right now, as part of version 1.0? Or phase it in with a
>>> temporary kwarg and/or rcparam? It would be nice to avoid all that
>>> complexity, but may be we can't, except by leaving everything as it is
>>> now.
>>>
>>> Eric
>>>
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

I'm +1 on making the proposed change prior to mpl 1.0 (ie now). Call
to set_xlim should turn off autoscaling for the x-axis on subsequent
plot calls. There may be some breakage in arcane corner cases, but
they will be exceptionally rare and easy to work around, and 1.0 is
the perfect time to introduce such breakages.

JDH

···

On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing <efiring@...229...> wrote:

You may well be right about this. In any case, I suspect no change will
occur prior to the 1.0 release.

> You may well be right about this. In any case, I suspect no change will
> occur prior to the 1.0 release.

I'm +1 on making the proposed change prior to mpl 1.0 (ie now). Call
to set_xlim should turn off autoscaling for the x-axis on subsequent
plot calls. There may be some breakage in arcane corner cases, but
they will be exceptionally rare and easy to work around, and 1.0 is
the perfect time to introduce such breakages.

I'm working on the change. I hope to have a patch some time
Wednesday.

Eric

···

On Tue, 2010-06-29 at 21:32 -0500, John Hunter wrote:

On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing <efiring@...229...> wrote:

JDH

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

My understanding is that the proposed change will break at least some
existing code, hence my proposal to go the safer route.

On what is that understanding based? Any actual examples or use cases?

I think the only such cases would be interactive scripts. One can
imagine a script in which a plot is made, the user views it, perhaps
uses a gui to change the limits, then presses a button to plot the next
data set on top of the first, expecting that it will again autoscale,
and so forth. Maybe this is sufficient justification for leaving the
present version alone. That is what I am trying to find out. In
addition, the change would require scanning the internal mpl code to see
whether there are uses of set_xlim that would have to be changed.

The points you make are exactly what I was thinking about.
A subtle alteration of the behaviour of matplotlib caused by the
change is the worse case scenario, because it might not be
straightforward to detect/correct.
I also have a number of matplotlib interactive scripts /GUIs used in
production. Most rely on precise control of the viewing area and some
will be affected by the change.

Also I'm unconvinced by the justification for the change :
xlim and autoscalex_on are independant attributes, why then should setting

They are not independent, they are potentially in conflict--two
mechanisms fighting for control of the axis.

xlim have the side effect of turning autoscalex off ? This is not consistent
with how the API works. If I really wanted autoscalex off, I would have
specified it.

The idea of having interactive plotting commands is to make the
interaction easy and natural. When you call set_xlim interactively, it
is because that is what you want the limits to be. At least that point
of view has been expressed several times on the lists. I have yet to
hear someone say, "I rely on the present behavior". In scripts, when
there is no interactive scenario such as I described in the previous
paragraph, the problem with the present behavior is that it means
set_xlim has no effect at all if followed by a plot command unless one
has disabled autoscaling either via a kwarg in the plot command, or via
ax.set_autoscalex_on(False). The latter is just plain ugly, to my eye.

My personal opinion is that the current behaviour is not broken.
When typing commands interactively in pylab or writing a regular
script it can be frustrating. But in interactive GUIs it is useful to
have full independent control over the two parameters.
In most cases I agree that the proposed behaviour is what the user
wants. But this is not true in all cases.

To sum things up:
Adding an argument to set_xlim to allow autoscale to be turned off in the
same step would be a good idea. But it shouldn't suddenly become the default
behaviour.

You may well be right about this. In any case, I suspect no change will
occur prior to the 1.0 release.

Additional perspective: the behavior of Matlab's xlim is as I have
proposed, not as mpl xlim presently works. I don't believe in following
Matlab slavishly--sometimes we can make better choices than Matlab
has--but I think that this is a case where Matlab got it right and we
did not, the first time around. This may be because the _autoscalex and
_autoscaley attributes were added to the mpl Axes long after set_xlim.

As the change of default behaviour seems to be going ahead, I must
request the addition of an new argument to xlim (autoscalex=False).
The purpose being to allow the user to modify his code to retain the
current behaviour when desired.

···

On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <efiring@...229...> wrote:

On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:

I made two commits, 8479 and 8480. Other developers are welcome to
revert them or modify them as needed. Certainly they need testing and
review, the more, the better. I had to change quite a few things, so
there is risk, as you note. I am a bit concerned about whether enough
people will be able to do enough testing of this before release to shake
out any bugs.

The new kwarg for set_xlim and set_ylim is simply "auto"; set it to None
to obtain the old behavior:

          *auto*: [ True | False | None ]
            turn *x* autoscaling on (True), off (False; default),
            or leave unchanged (None)

set_xbound retains the old behavior, by calling set_xlim with auto=None.

We have several options at present. If the changes I made are junk,
they can be discarded, or deferred until more time is available for
testing and reworking. If they are basically sound but too abrupt, then
the default could be changed to auto=None, with the possibility of
shifting it later. Additionally, an rcparam could be used, although I
don't like making ever more rcparams.

In addition to the changes to set_xlim, I tried to clarify the
documentation, and I added an "autoscale" convenience method and pyplot
function, which I think was needed.

One more change I would like to see is the simple and, I think, safe one
of supporting descriptive kwarg names alongside the present misleading
ones: e.g. for xlim, "left" would be equivalent to "xmin", etc.

I am on a ship until July 5, working with a high-latency internet
connection through an intermediate machine, and I can't afford much more
time on this while I am out here. (And working with svn from here is
pretty cumbersome.)

Eric

···

On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:

On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <efiring@...229...> wrote:
> On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
>> My understanding is that the proposed change will break at least some
>> existing code, hence my proposal to go the safer route.
>
> On what is that understanding based? Any actual examples or use cases?
>
> I think the only such cases would be interactive scripts. One can
> imagine a script in which a plot is made, the user views it, perhaps
> uses a gui to change the limits, then presses a button to plot the next
> data set on top of the first, expecting that it will again autoscale,
> and so forth. Maybe this is sufficient justification for leaving the
> present version alone. That is what I am trying to find out. In
> addition, the change would require scanning the internal mpl code to see
> whether there are uses of set_xlim that would have to be changed.

The points you make are exactly what I was thinking about.
A subtle alteration of the behaviour of matplotlib caused by the
change is the worse case scenario, because it might not be
straightforward to detect/correct.
I also have a number of matplotlib interactive scripts /GUIs used in
production. Most rely on precise control of the viewing area and some
will be affected by the change.

>
>>
>> Also I'm unconvinced by the justification for the change :
>> xlim and autoscalex_on are independant attributes, why then should setting
>
> They are not independent, they are potentially in conflict--two
> mechanisms fighting for control of the axis.
>
>> xlim have the side effect of turning autoscalex off ? This is not consistent
>> with how the API works. If I really wanted autoscalex off, I would have
>> specified it.
>
> The idea of having interactive plotting commands is to make the
> interaction easy and natural. When you call set_xlim interactively, it
> is because that is what you want the limits to be. At least that point
> of view has been expressed several times on the lists. I have yet to
> hear someone say, "I rely on the present behavior". In scripts, when
> there is no interactive scenario such as I described in the previous
> paragraph, the problem with the present behavior is that it means
> set_xlim has no effect at all if followed by a plot command unless one
> has disabled autoscaling either via a kwarg in the plot command, or via
> ax.set_autoscalex_on(False). The latter is just plain ugly, to my eye.

My personal opinion is that the current behaviour is not broken.
When typing commands interactively in pylab or writing a regular
script it can be frustrating. But in interactive GUIs it is useful to
have full independent control over the two parameters.
In most cases I agree that the proposed behaviour is what the user
wants. But this is not true in all cases.

>> To sum things up:
>> Adding an argument to set_xlim to allow autoscale to be turned off in the
>> same step would be a good idea. But it shouldn't suddenly become the default
>> behaviour.
>
> You may well be right about this. In any case, I suspect no change will
> occur prior to the 1.0 release.
>
> Additional perspective: the behavior of Matlab's xlim is as I have
> proposed, not as mpl xlim presently works. I don't believe in following
> Matlab slavishly--sometimes we can make better choices than Matlab
> has--but I think that this is a case where Matlab got it right and we
> did not, the first time around. This may be because the _autoscalex and
> _autoscaley attributes were added to the mpl Axes long after set_xlim.

As the change of default behaviour seems to be going ahead, I must
request the addition of an new argument to xlim (autoscalex=False).
The purpose being to allow the user to modify his code to retain the
current behaviour when desired.

Do we want to add a note to the CHANGELOG for this?

Ben Root

···

On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing <efiring@…229…> wrote:

On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:

On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <efiring@…229…> wrote:

On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:

My understanding is that the proposed change will break at least some

existing code, hence my proposal to go the safer route.

On what is that understanding based? Any actual examples or use cases?

I think the only such cases would be interactive scripts. One can

imagine a script in which a plot is made, the user views it, perhaps

uses a gui to change the limits, then presses a button to plot the next

data set on top of the first, expecting that it will again autoscale,

and so forth. Maybe this is sufficient justification for leaving the

present version alone. That is what I am trying to find out. In

addition, the change would require scanning the internal mpl code to see

whether there are uses of set_xlim that would have to be changed.

The points you make are exactly what I was thinking about.

A subtle alteration of the behaviour of matplotlib caused by the

change is the worse case scenario, because it might not be

straightforward to detect/correct.

I also have a number of matplotlib interactive scripts /GUIs used in

production. Most rely on precise control of the viewing area and some

will be affected by the change.

Also I’m unconvinced by the justification for the change :

xlim and autoscalex_on are independant attributes, why then should setting

They are not independent, they are potentially in conflict–two

mechanisms fighting for control of the axis.

xlim have the side effect of turning autoscalex off ? This is not consistent

with how the API works. If I really wanted autoscalex off, I would have

specified it.

The idea of having interactive plotting commands is to make the

interaction easy and natural. When you call set_xlim interactively, it

is because that is what you want the limits to be. At least that point

of view has been expressed several times on the lists. I have yet to

hear someone say, “I rely on the present behavior”. In scripts, when

there is no interactive scenario such as I described in the previous

paragraph, the problem with the present behavior is that it means

set_xlim has no effect at all if followed by a plot command unless one

has disabled autoscaling either via a kwarg in the plot command, or via

ax.set_autoscalex_on(False). The latter is just plain ugly, to my eye.

My personal opinion is that the current behaviour is not broken.

When typing commands interactively in pylab or writing a regular

script it can be frustrating. But in interactive GUIs it is useful to

have full independent control over the two parameters.

In most cases I agree that the proposed behaviour is what the user

wants. But this is not true in all cases.

To sum things up:

Adding an argument to set_xlim to allow autoscale to be turned off in the

same step would be a good idea. But it shouldn’t suddenly become the default

behaviour.

You may well be right about this. In any case, I suspect no change will

occur prior to the 1.0 release.

Additional perspective: the behavior of Matlab’s xlim is as I have

proposed, not as mpl xlim presently works. I don’t believe in following

Matlab slavishly–sometimes we can make better choices than Matlab

has–but I think that this is a case where Matlab got it right and we

did not, the first time around. This may be because the _autoscalex and

_autoscaley attributes were added to the mpl Axes long after set_xlim.

As the change of default behaviour seems to be going ahead, I must

request the addition of an new argument to xlim (autoscalex=False).

The purpose being to allow the user to modify his code to retain the

current behaviour when desired.

I made two commits, 8479 and 8480. Other developers are welcome to

revert them or modify them as needed. Certainly they need testing and

review, the more, the better. I had to change quite a few things, so

there is risk, as you note. I am a bit concerned about whether enough

people will be able to do enough testing of this before release to shake

out any bugs.

The new kwarg for set_xlim and set_ylim is simply “auto”; set it to None

to obtain the old behavior:

      *auto*: [ True | False | None ]

        turn *x* autoscaling on (True), off (False; default),

        or leave unchanged (None)

set_xbound retains the old behavior, by calling set_xlim with auto=None.

We have several options at present. If the changes I made are junk,

they can be discarded, or deferred until more time is available for

testing and reworking. If they are basically sound but too abrupt, then

the default could be changed to auto=None, with the possibility of

shifting it later. Additionally, an rcparam could be used, although I

don’t like making ever more rcparams.

In addition to the changes to set_xlim, I tried to clarify the

documentation, and I added an “autoscale” convenience method and pyplot

function, which I think was needed.

One more change I would like to see is the simple and, I think, safe one

of supporting descriptive kwarg names alongside the present misleading

ones: e.g. for xlim, “left” would be equivalent to “xmin”, etc.

I am on a ship until July 5, working with a high-latency internet

connection through an intermediate machine, and I can’t afford much more

time on this while I am out here. (And working with svn from here is

pretty cumbersome.)

Eric


This SF.net email is sponsored by Sprint

What will you do first with EVO, the first 4G phone?

Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first


Matplotlib-devel mailing list

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Do we want to add a note to the CHANGELOG for this?

I did.

Eric

···

On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:

Ben Root

On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing <efiring@...229...> > wrote:
        
        On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
        > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing > <efiring@...229...> wrote:
        > > On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
        > >> My understanding is that the proposed change will break
        at least some
        > >> existing code, hence my proposal to go the safer route.
        > >
        > > On what is that understanding based? Any actual examples
        or use cases?
        > >
        > > I think the only such cases would be interactive scripts.
         One can
        > > imagine a script in which a plot is made, the user views
        it, perhaps
        > > uses a gui to change the limits, then presses a button to
        plot the next
        > > data set on top of the first, expecting that it will again
        autoscale,
        > > and so forth. Maybe this is sufficient justification for
        leaving the
        > > present version alone. That is what I am trying to find
        out. In
        > > addition, the change would require scanning the internal
        mpl code to see
        > > whether there are uses of set_xlim that would have to be
        changed.
        >
        > The points you make are exactly what I was thinking about.
        > A subtle alteration of the behaviour of matplotlib caused by
        the
        > change is the worse case scenario, because it might not be
        > straightforward to detect/correct.
        > I also have a number of matplotlib interactive scripts /GUIs
        used in
        > production. Most rely on precise control of the viewing area
        and some
        > will be affected by the change.
        >
        > >
        > >>
        > >> Also I'm unconvinced by the justification for the
        change :
        > >> xlim and autoscalex_on are independant attributes, why
        then should setting
        > >
        > > They are not independent, they are potentially in
        conflict--two
        > > mechanisms fighting for control of the axis.
        > >
        > >> xlim have the side effect of turning autoscalex off ?
        This is not consistent
        > >> with how the API works. If I really wanted autoscalex
        off, I would have
        > >> specified it.
        > >
        > > The idea of having interactive plotting commands is to
        make the
        > > interaction easy and natural. When you call set_xlim
        interactively, it
        > > is because that is what you want the limits to be. At
        least that point
        > > of view has been expressed several times on the lists. I
        have yet to
        > > hear someone say, "I rely on the present behavior". In
        scripts, when
        > > there is no interactive scenario such as I described in
        the previous
        > > paragraph, the problem with the present behavior is that
        it means
        > > set_xlim has no effect at all if followed by a plot
        command unless one
        > > has disabled autoscaling either via a kwarg in the plot
        command, or via
        > > ax.set_autoscalex_on(False). The latter is just plain
        ugly, to my eye.
        >
        > My personal opinion is that the current behaviour is not
        broken.
        > When typing commands interactively in pylab or writing a
        regular
        > script it can be frustrating. But in interactive GUIs it is
        useful to
        > have full independent control over the two parameters.
        > In most cases I agree that the proposed behaviour is what
        the user
        > wants. But this is not true in all cases.
        >
        > >> To sum things up:
        > >> Adding an argument to set_xlim to allow autoscale to be
        turned off in the
        > >> same step would be a good idea. But it shouldn't suddenly
        become the default
        > >> behaviour.
        > >
        > > You may well be right about this. In any case, I suspect
        no change will
        > > occur prior to the 1.0 release.
        > >
        > > Additional perspective: the behavior of Matlab's xlim is
        as I have
        > > proposed, not as mpl xlim presently works. I don't
        believe in following
        > > Matlab slavishly--sometimes we can make better choices
        than Matlab
        > > has--but I think that this is a case where Matlab got it
        right and we
        > > did not, the first time around. This may be because the
        _autoscalex and
        > > _autoscaley attributes were added to the mpl Axes long
        after set_xlim.
        >
        > As the change of default behaviour seems to be going ahead,
        I must
        > request the addition of an new argument to xlim
        (autoscalex=False).
        > The purpose being to allow the user to modify his code to
        retain the
        > current behaviour when desired.
        
        I made two commits, 8479 and 8480. Other developers are
        welcome to
        revert them or modify them as needed. Certainly they need
        testing and
        review, the more, the better. I had to change quite a few
        things, so
        there is risk, as you note. I am a bit concerned about
        whether enough
        people will be able to do enough testing of this before
        release to shake
        out any bugs.
        
        The new kwarg for set_xlim and set_ylim is simply "auto"; set
        it to None
        to obtain the old behavior:
        
                 *auto*: [ True | False | None ]
                   turn *x* autoscaling on (True), off (False;
        default),
                   or leave unchanged (None)
        
        set_xbound retains the old behavior, by calling set_xlim with
        auto=None.
        
        We have several options at present. If the changes I made are
        junk,
        they can be discarded, or deferred until more time is
        available for
        testing and reworking. If they are basically sound but too
        abrupt, then
        the default could be changed to auto=None, with the
        possibility of
        shifting it later. Additionally, an rcparam could be used,
        although I
        don't like making ever more rcparams.
        
        In addition to the changes to set_xlim, I tried to clarify the
        documentation, and I added an "autoscale" convenience method
        and pyplot
        function, which I think was needed.
        
        One more change I would like to see is the simple and, I
        think, safe one
        of supporting descriptive kwarg names alongside the present
        misleading
        ones: e.g. for xlim, "left" would be equivalent to "xmin",
        etc.
        
        I am on a ship until July 5, working with a high-latency
        internet
        connection through an intermediate machine, and I can't afford
        much more
        time on this while I am out here. (And working with svn from
        here is
        pretty cumbersome.)
        
        Eric
        
        ------------------------------------------------------------------------------
        This SF.net email is sponsored by Sprint
        What will you do first with EVO, the first 4G phone?
        Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
        _______________________________________________
        Matplotlib-devel mailing list
        Matplotlib-devel@lists.sourceforge.net
        https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
        
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Oops, sorry, that’ll teach me to check more than just the last diff!

Ben

···

On Sat, Jul 3, 2010 at 2:11 PM, Eric Firing <efiring@…229…> wrote:

On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:

Do we want to add a note to the CHANGELOG for this?

I did.

Eric

Ben Root

On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing <efiring@…229…> > > > wrote:

    On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
    > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing >  > >         <efiring@...865...9...> wrote:
    > > On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
    > >> My understanding is that the proposed change will break
    at least some
    > >> existing code, hence my proposal to go the safer route.
    > >
    > > On what is that understanding based?  Any actual examples
    or use cases?
    > >
    > > I think the only such cases would be interactive scripts.
     One can
    > > imagine a script in which a plot is made, the user views
    it, perhaps
    > > uses a gui to change the limits, then presses a button to
    plot the next
    > > data set on top of the first, expecting that it will again
    autoscale,
    > > and so forth.  Maybe this is sufficient justification for
    leaving the
    > > present version alone.  That is what I am trying to find
    out.  In
    > > addition, the change would require scanning the internal
    mpl code to see
    > > whether there are uses of set_xlim that would have to be
    changed.
    >
    > The points you make are exactly what I was thinking about.
    > A subtle alteration of the behaviour of matplotlib caused by
    the
    > change is the worse case scenario, because it might not be
    > straightforward to detect/correct.
    > I also have a number of matplotlib interactive scripts /GUIs
    used in
    > production. Most rely on precise control of the viewing area
    and some
    > will be affected by the change.
    >
    > >
    > >>
    > >> Also I'm unconvinced by the justification for the
    change :
    > >> xlim and autoscalex_on are independant attributes, why
    then should setting
    > >
    > > They are not independent, they are potentially in
    conflict--two
    > > mechanisms fighting for control of the axis.
    > >
    > >> xlim have the side effect of turning autoscalex off ?
    This is not consistent
    > >> with how the API works. If I really wanted autoscalex
    off, I would have
    > >> specified it.
    > >
    > > The idea of having interactive plotting commands is to
    make the
    > > interaction easy and natural.  When you call set_xlim
    interactively, it
    > > is because that is what you want the limits to be.  At
    least that point
    > > of view has been expressed several times on the lists.  I
    have yet to
    > > hear someone say, "I rely on the present behavior".  In
    scripts, when
    > > there is no interactive scenario such as I described in
    the previous
    > > paragraph, the problem with the present behavior is that
    it means
    > > set_xlim has no effect at all if followed by a plot
    command unless one
    > > has disabled autoscaling either via a kwarg in the plot
    command, or via
    > > ax.set_autoscalex_on(False).  The latter is just plain
    ugly, to my eye.
    >
    > My personal opinion is that the current behaviour is not
    broken.
    > When typing commands interactively in pylab or writing a
    regular
    > script it can be frustrating. But in interactive GUIs it is
    useful to
    > have full independent control over the two parameters.
    > In most cases I agree that the proposed behaviour is what
    the user
    > wants. But this is not true in all cases.
    >
    > >> To sum things up:
    > >> Adding an argument to set_xlim to allow autoscale to be
    turned off in the
    > >> same step would be a good idea. But it shouldn't suddenly
    become the default
    > >> behaviour.
    > >
    > > You may well be right about this.  In any case, I suspect
    no change will
    > > occur prior to the 1.0 release.
    > >
    > > Additional perspective: the behavior of Matlab's xlim is
    as I have
    > > proposed, not as mpl xlim presently works.  I don't
    believe in following
    > > Matlab slavishly--sometimes we can make better choices
    than Matlab
    > > has--but I think that this is a case where Matlab got it
    right and we
    > > did not, the first time around.  This may be because the
    _autoscalex and
    > > _autoscaley attributes were added to the mpl Axes long
    after set_xlim.
    >
    > As the change of default behaviour seems to be going ahead,
    I must
    > request the addition of an new argument to xlim
    (autoscalex=False).
    > The purpose being to allow the user to modify his code to
    retain the
    > current behaviour when desired.
    I made two commits, 8479 and 8480.  Other developers are
    welcome to
    revert them or modify them as needed.  Certainly they need
    testing and
    review, the more, the better.  I had to change quite a few
    things, so
    there is risk, as you note.  I am a bit concerned about
    whether enough
    people will be able to do enough testing of this before
    release to shake
    out any bugs.
    The new kwarg for set_xlim and set_ylim is simply "auto"; set
    it to None
    to obtain the old behavior:
             *auto*: [ True | False | None ]
               turn *x* autoscaling on (True), off (False;
    default),
               or leave unchanged (None)
    set_xbound retains the old behavior, by calling set_xlim with
    auto=None.
    We have several options at present.  If the changes I made are
    junk,
    they can be discarded, or deferred until more time is
    available for
    testing and reworking.  If they are basically sound but too
    abrupt, then
    the default could be changed to auto=None, with the
    possibility of
    shifting it later.  Additionally, an rcparam could be used,
    although I
    don't like making ever more rcparams.
    In addition to the changes to set_xlim, I tried to clarify the
    documentation, and I added an "autoscale" convenience method
    and pyplot
    function, which I think was needed.
    One more change I would like to see is the simple and, I
    think, safe one
    of supporting descriptive kwarg names alongside the present
    misleading
    ones: e.g. for xlim, "left" would be equivalent to "xmin",
    etc.
    I am on a ship until July 5, working with a high-latency
    internet
    connection through an intermediate machine, and I can't afford
    much more
    time on this while I am out here. (And working with svn from
    here is
    pretty cumbersome.)
    Eric
    ------------------------------------------------------------------------------
    This SF.net email is sponsored by Sprint
    What will you do first with EVO, the first 4G phone?
    Visit [sprint.com/first](http://sprint.com/first) -- [http://p.sf.net/sfu/sprint-com-first](http://p.sf.net/sfu/sprint-com-first)
    _______________________________________________
    Matplotlib-devel mailing list
    Matplotlib-devel@lists.sourceforge.net
    [https://lists.sourceforge.net/lists/listinfo/matplotlib-devel](https://lists.sourceforge.net/lists/listinfo/matplotlib-devel)

This SF.net email is sponsored by Sprint

What will you do first with EVO, the first 4G phone?

Visit sprint.com/firsthttp://p.sf.net/sfu/sprint-com-first

_______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel