matplotlib-devel Mailing List for matplotlib

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 Jun 29, 2010, at 5:08 PM, Andrew Straw <str...@as...> wrote:

> John Hunter wrote:
>> On Sun, Jun 20, 2010 at 7:56 PM,
>>>
>>> However, the link to trunk-docs still does not work.
>>>
>>> http://matplotlib.sourceforge.net/trunk-docs/
>>>
>>
>
> I believe I fixed the issue in svn r8477.
>
> Now, to fix the false alarm warnings that the buildbot give out so we
> catch this earlier.
>
> Hi to all at the SciPy conference -- I'm sorry I'll miss it this year.
>

Well the site is up so that is the acid test. Michael, you can refer  
to this for gallery screenshots and examples. You may also want to  
provide the link along with the rc announcement for those who want  
docs and examples. Your 2 min talk is growing :-)

Thanks for the quick fix, Andrew.

John Hunter wrote:
> On Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee <lee...@gm...> wrote:
>   
>> The issue was related with the change in Sphinx v1.0b2, which I think
>> I fixed in r8447.
>> At least, the html are built fine and uploaded fine.
>>
>> However, the link to trunk-docs still does not work.
>>
>> http://matplotlib.sourceforge.net/trunk-docs/
>>
>> Can someone check what's wrong?
>>     
>
> Andrew, any chance you can look at this before tomorrow AM?  We are
> putting out a 1.0 release candidate ahead of scipy, and Michael is
> giving a "what's new" talk tomorrow, and it would be nice if he could
> illustrate some stuff in the gallery of the trunk-docs

I believe I fixed the issue in svn r8477.

Now, to fix the false alarm warnings that the buildbot give out so we
catch this earlier.

Hi to all at the SciPy conference -- I'm sorry I'll miss it this year.

-Andrew

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 Sun, Jun 20, 2010 at 7:56 PM, Jae-Joon Lee <lee...@gm...> wrote:
> The issue was related with the change in Sphinx v1.0b2, which I think
> I fixed in r8447.
> At least, the html are built fine and uploaded fine.
>
> However, the link to trunk-docs still does not work.
>
> http://matplotlib.sourceforge.net/trunk-docs/
>
> Can someone check what's wrong?

Andrew, any chance you can look at this before tomorrow AM?  We are
putting out a 1.0 release candidate ahead of scipy, and Michael is
giving a "what's new" talk tomorrow, and it would be nice if he could
illustrate some stuff in the gallery of the trunk-docs

JDH

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
>

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

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.