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
> <[email protected]> wrote:
> On 28 June 2010 23:11, Eric Firing <[email protected]> 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
> > [email protected]
> >
> 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
> [email protected]
> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
