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 <ef...@ha...> 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 > Mat...@li... > 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 <peb...@gm...> 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 <ef...@ha...> 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 > > Mat...@li... > > 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 > Mat...@li... > 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.
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 >> >
On 28 June 2010 23:11, Eric Firing <ef...@ha...> 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 > Mat...@li... > 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 <aar...@ph...
> wrote:
> On 28 June 2010 23:11, Eric Firing <ef...@ha...> 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
> > Mat...@li...
> > 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
On Tue, 2010年06月29日 at 15:32 -0500, Benjamin Root wrote:
> 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
>
> Ben Root
>
> On Mon, Jun 28, 2010 at 10:48 PM, Anne Archibald
> <aar...@ph...> wrote:
> On 28 June 2010 23:11, Eric Firing <ef...@ha...> 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
> > Mat...@li...
> >
> 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
> Mat...@li...
> 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 Mat...@li... 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 > Mat...@li... > 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.
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. > > 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 > > > 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 > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > >
On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing <ef...@ha...> wrote: > 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. JDH
On Tue, 2010年06月29日 at 21:32 -0500, John Hunter wrote: > On Tue, Jun 29, 2010 at 8:42 PM, Eric Firing <ef...@ha...> wrote: > > 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 > > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <ef...@ha...> 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.
On Wed, 2010年06月30日 at 23:08 +0200, Peter Butterworth wrote: > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <ef...@ha...> 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
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 <ef...@ha...> wrote: > On Wed, 2010年06月30日 at 23:08 +0200, Peter Butterworth wrote: > > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <ef...@ha...> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
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 <ef...@ha...> > wrote: > > On Wed, 2010年06月30日 at 23:08 +0200, Peter Butterworth wrote: > > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing > <ef...@ha...> 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 > Mat...@li... > 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 Mat...@li... 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 <ef...@ha...> 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 <ef...@ha...> > > wrote: > > > > On Wed, 2010年06月30日 at 23:08 +0200, Peter Butterworth wrote: > > > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing > > <ef...@ha...> 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 > > Mat...@li... > > 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 Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > >