Menu
▾
▴
Re: [matplotlib-devel] should set_xlim turn off x autoscaling?
|
From: Benjamin R. <ben...@ou...> - 2010-07-03 19:35:24
|
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 > > > |
