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/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