matplotlib-devel Mailing List for matplotlib

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

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

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
>

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
>

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 06/26/2010 04:13 PM, Jae-Joon Lee wrote:
> In r8472, I tried to modify the image slicing so that it works even if
> images are rotated and skewed. And the "noslice" option is now gon.
> Let me know if it causes any problem.

Thanks very much, JJ, that's great!

Eric

>
> Regards,
>
> -JJ

In r8472, I tried to modify the image slicing so that it works even if
images are rotated and skewed. And the "noslice" option is now gon.
Let me know if it causes any problem.

Regards,

-JJ


On Tue, Jun 22, 2010 at 11:05 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Eric,
>
> I should have left more comments about my change.
> The issue is that the current slicing algorithm sometimes fails with
> "_draw_unsampled_image" which support arbitrary affine transformation
> of the image. The slicing gets wrong when the image is significantly
> skewed or rotated. So, as a temporary measure, I simply wanted to
> disable the slicing until we have a correct algorithm in place.
>
> I guess a quick (still temporary) fix is to check if affine transform
> is needed, and do the slicing if not.
> Something like below. The condition is not exactly correct, but I
> think it would work in most of cases.
> I actually didn't test the patch. I'll be out of town until the end of
> this week.
>
> On a second thought, I think it should not be difficult to workaround
> the slicing thing for arbitrary affine transform. I'll think about the
> whole issue again when I get back. If you have a better idea, please
> go ahead and implement.
>
> Regards,
>
> -JJ
>
> diff --git a/lib/matplotlib/image.py b/lib/matplotlib/image.py
> index 7c1128f..b65f446 100644
> --- a/lib/matplotlib/image.py
> +++ b/lib/matplotlib/image.py
> @@ -248,9 +248,14 @@ class _AxesImageBase(martist.Artist, cm.ScalarMappable):
>         """
>
>
> +        if self._image_skew_coordinate:
> +            no_slice = True
> +        else:
> +            no_slice = False
> +
>         im, xmin, ymin, dxintv, dyintv, sx, sy = \
>             self._get_unsampled_image(self._A, self.get_extent(),
> -                                      self.axes.viewLim, noslice=True)
> +                                      self.axes.viewLim, noslice=no_slice)
>
>         if im is None: return # I'm not if this check is required. -JJL
>
>
>
> On Tue, Jun 22, 2010 at 8:45 PM, Eric Firing <ef...@ha...> wrote:
>> JJ,
>>
>> In AxesImageBase._draw_unsampled_image, there is a call to
>> _get_unsampled_image(...noslice=True).  When using imshow(Z,
>> interpolation='nearest'), this defeats the slicing that makes such a
>> difference when zooming and panning a small chunk of a large image. Changing
>> it to False makes imshow work better; I don't understand why one would ever
>> want noslice=True.  Am I missing something?  Can we just change it to False?
>>  Or remove the noslice option and kwarg entirely?
>>
>> Eric
>>
>

SVN r8457 has what I think is an ideal solution.  Unbeknownst to me, the 
clipping I added to speed up rendering of highly magnified images was 
being done in integers.  Agg does provide an option to do this in 
doubles, and using that seems to prevent the image from disappearing.  
It even renders the image with the very narrow range that nonsingular() 
currently enforces (+/- 0.001).

Mike

On 06/23/2010 08:37 AM, Michael Droettboom wrote:
> On 06/22/2010 06:56 PM, Eric Firing wrote:
>    
>>      
>>> Unfortunately, this fix paves over the exception fixed earlier. Rather
>>> than getting an exception when the magnification is too high, it now
>>> silently just doesn't draw the image. I'm trying to figure out what the
>>> threshold is beyond which it fails in order to manually raise an
>>> exception, but not having much luck. I suspect it's somehow related to
>>> floating-point or even Agg's fixed-point rounding error.
>>>
>>>        
>> "just doesn't draw" sounds like a pretty benign failure mode.  It might
>> even be better than raising an exception.
>>      
> I was just imagining the frequent questions "my image disappears when I
> zoom in".  I think it's preferable to have an exception (or at least a
> warning) saying something useful in that case.
>    
>>    An alternative might be to
>> use something like "nonsingular()" to block attempts to make the view
>> limits too small--once it is known how to calculate "too small".
>>      
> Yes.  That's not a bad middle ground between raising an exception and
> doing nothing -- however this only applies to images, so nonsingular()
> or autoscale_view() etc. would have to become aware of when an image was
> on the axes.  Not too difficult, I suppose.
>    
>>     Yet
>> another alternative, more complicated to implement, would be to clip the
>> array and then interpolate to a finer grid at the python level when
>> trying to zoom too far into a cell of the original grid.
>>
>>      
> Yes, perhaps.  But that means reimplementing all of the interpolation
> algorithms we currently use Agg for at the Python level, right?  Doing a
> simple nearest neighbor interpolation in Python and then one of the more
> involved interpolation methods in Agg would not be equivalent.  Such
> effort might be worth it in the long run to support non-regular grids,
> quadmeshes etc., however.  But that's a major project and would probably
> need to be implemented in C/C++ anyway, just not necessarily based on Agg.
>    
>> It would be good if everything could be kept at the python or _image.cpp
>> level, so that the Agg code could be left unchanged.  As far as I know,
>> your previous patch to raise the exception was the only mpl-specific
>> change that has been made to the Agg24 code.
>>
>>      
> There are other changes that have been made over time to keep it
> compatible with newer versions of compilers.  As the upstream of the
> non-GPL version of Agg is basically dead (and AFAICT the GPL'd version
> is too), we're maintaining such changes ourselves.
>
> That said, the pulling of CXX classes into Agg is ugly, but it was the
> quickest solution (and one that will work for Debian as a basic patch
> against matplotlib 0.99.3).  In the long run, the exception should be
> generic as far as Agg is concerned, and try/catch's need to be added
> around all calls into Agg from our Python wrappers.
>
> Mike
>    
>> Eric
>>
>>
>>
>>      
>>> Mike
>>>
>>> On 06/22/2010 12:31 PM, Michael Droettboom wrote:
>>>
>>>        
>>>> Ok. Attached is a corrected patch.
>>>>
>>>> Mike
>>>>
>>>> On 06/22/2010 12:26 PM, Michael Droettboom wrote:
>>>>
>>>>          
>>>>> Hold off, actually. This patch seems to have broken some thing
>>>>> inadvertently. Stay tuned...
>>>>>
>>>>> Mike
>>>>>
>>>>> On 06/22/2010 12:05 PM, Michael Droettboom wrote:
>>>>>
>>>>>            
>>>>>> In r8454, I have a applied a fix that allows this C++ exception to
>>>>>> correctly percolate to the Python side -- the user will still get an
>>>>>> exception, but it will be a Python exception and the interpreter
>>>>>> itself does not crash. (It used to work, but recent changes to CXX
>>>>>> caused it to break.) I have attached this patch to the e-mail.
>>>>>>
>>>>>> As Eric suggests, fixing the underlying limitation (I even hesitate
>>>>>> to call it a bug because it is definitely a corner case) requires
>>>>>> understanding some pretty dark depths of the Agg renderer.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> On 06/21/2010 10:57 PM, Eric Firing wrote:
>>>>>>
>>>>>>              
>>>>>>> On 06/21/2010 12:24 PM, Sandro Tosi wrote:
>>>>>>>
>>>>>>>                
>>>>>>>> forwarded 585442 mat...@li...
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> Hello Matplotlib developers,
>>>>>>>> here below is a report a user of maplotlib sent to the Debian bug
>>>>>>>> tracker. I've verified and it happend also with 0.99.3:
>>>>>>>>
>>>>>>>> $ python -c "import matplotlib as p ; print p.__version__"
>>>>>>>> 0.99.3
>>>>>>>> $ python mpl_crash.py
>>>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>>>> Aborted
>>>>>>>>
>>>>>>>> Thanks for looking into it,
>>>>>>>> Sandro
>>>>>>>>
>>>>>>>>                  
>>>>>>> Sandro,
>>>>>>>
>>>>>>> Thanks for reporting it.
>>>>>>>
>>>>>>> With the default interpolation, rendering gets extremely slow as the
>>>>>>> view limits decline to and below a single image pixel. I suspect the
>>>>>>> crash is related to this. Neither the slowdown nor the crash occurs
>>>>>>> with interpolation='nearest', although there is still an anomaly in
>>>>>>> which the image is blank when the viewlim region is too small.
>>>>>>>
>>>>>>> Like Ryan, I am not familiar with the _image.cpp and the underlying
>>>>>>> agg
>>>>>>> routines, but I suspect this is going to be a difficult problem to
>>>>>>> solve. It may be necessary to put in some workaround, trying to trap
>>>>>>> and prevent the extreme slowdown and crash. The slowdown topic came up
>>>>>>> on the list years ago.
>>>>>>>
>>>>>>> http://www.mail-archive.com/mat...@li.../msg00513.html
>>>>>>>
>>>>>>>
>>>>>>> Eric
>>>>>>>
>>>>>>>
>>>>>>>                
>>>>>>>> On Thu, Jun 10, 2010 at 16:52, Teemu Ikonen<tpi...@gm...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>                  
>>>>>>>>> Package: python-matplotlib
>>>>>>>>> Version: 0.99.1.2-3
>>>>>>>>> Severity: important
>>>>>>>>>
>>>>>>>>> Running a program which displays an image with plt.imshow() and
>>>>>>>>> changes the
>>>>>>>>> axes with plt.axis() before calling plt.show() crashes the python
>>>>>>>>> interpreter:
>>>>>>>>>
>>>>>>>>> $ python mpl_crash.py
>>>>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>>>>> Aborted
>>>>>>>>>
>>>>>>>>> This happens at least with Qt4Agg, GTKAgg and TKAgg backends.
>>>>>>>>>
>>>>>>>>> The example program is attached.
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>>
>>>>>>>>> Teemu
>>>>>>>>>
>>>>>>>>> -- System Information:
>>>>>>>>> Debian Release: squeeze/sid
>>>>>>>>> APT prefers testing
>>>>>>>>> APT policy: (500, 'testing')
>>>>>>>>> Architecture: amd64 (x86_64)
>>>>>>>>>
>>>>>>>>> Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
>>>>>>>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>>>>>>>> Shell: /bin/sh linked to /bin/dash
>>>>>>>>>
>>>>>>>>> Versions of packages python-matplotlib depends on:
>>>>>>>>> ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
>>>>>>>>> ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
>>>>>>>>> ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra
>>>>>>>>> ii libfontconfig1 2.8.0-2.1 generic font configuration library
>>>>>>>>> ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib
>>>>>>>>> ii libgcc1 1:4.4.4-1 GCC support library
>>>>>>>>> ii libglib2.0-0 2.24.1-1 The GLib library of C routines
>>>>>>>>> ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface
>>>>>>>>> ii libpango1.0-0 1.28.0-1 Layout and rendering of internatio
>>>>>>>>> ii libpng12-0 1.2.43-1 PNG library - runtime
>>>>>>>>> ii libstdc++6 4.4.4-1 The GNU Standard C++ Library v3
>>>>>>>>> ii python 2.5.4-9 An interactive high-level object-o
>>>>>>>>> ii python-cairo 1.8.8-1+b1 Python bindings for the Cairo vect
>>>>>>>>> ii python-dateutil 1.4.1-3 powerful extensions to the standar
>>>>>>>>> ii python-gobject 2.21.1-1 Python bindings for the GObject li
>>>>>>>>> ii python-matplotlib-data 0.99.1.2-3 Python based plotting system
>>>>>>>>> (data
>>>>>>>>> ii python-numpy 1:1.3.0-3+b1 Numerical Python adds a fast array
>>>>>>>>> ii python-pyparsing 1.5.2-2 Python parsing module
>>>>>>>>> ii python-support 1.0.8 automated rebuilding support for P
>>>>>>>>> ii python-tz 2010b-1 Python version of the Olson timezo
>>>>>>>>> ii tcl8.5 8.5.8-2 Tcl (the Tool Command Language) v8
>>>>>>>>> ii tk8.5 8.5.8-1 Tk toolkit for Tcl and X11, v8.5 -
>>>>>>>>> ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
>>>>>>>>>
>>>>>>>>> Versions of packages python-matplotlib recommends:
>>>>>>>>> ii python-glade2 2.17.0-2 GTK+ bindings: Glade support
>>>>>>>>> ii python-tk 2.6.5-1 Tkinter - Writing Tk applications
>>>>>>>>>
>>>>>>>>> Versions of packages python-matplotlib suggests:
>>>>>>>>> ii dvipng 1.13-1 convert DVI files to PNG graphics
>>>>>>>>> ii ipython 0.10-2 enhanced interactive Python shell
>>>>>>>>> ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG
>>>>>>>>> ii python-configobj 4.7.2+ds-1 simple but powerful config file re
>>>>>>>>> pn python-excelerator<none>   (no description available)
>>>>>>>>> ii python-gtk2 2.17.0-2 Python bindings for the GTK+ widge
>>>>>>>>> pn python-matplotlib-doc<none>   (no description available)
>>>>>>>>> pn python-qt3<none>   (no description available)
>>>>>>>>> ii python-qt4 4.7.3-1 Python bindings for Qt4
>>>>>>>>> ii python-scipy 0.7.2-1 scientific tools for Python
>>>>>>>>> ii python-traits 3.3.0-1 Manifest typing and reactive progr
>>>>>>>>> ii python-wxgtk2.8 2.8.10.1-3 wxWidgets Cross-platform C++ GUI t
>>>>>>>>> ii texlive-extra-utils 2009-7 TeX Live: TeX auxiliary programs
>>>>>>>>> ii texlive-latex-extra 2009-7 TeX Live: LaTeX supplementary pack
>>>>>>>>>
>>>>>>>>> -- no debconf information
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Python-modules-team mailing list
>>>>>>>>> Pyt...@li...
>>>>>>>>> http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>>>> lucky parental unit. See the prize list and enter to win:
>>>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Matplotlib-devel mailing list
>>>>>>>> Mat...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>>
>>>>>>>>                  
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>>> lucky parental unit. See the prize list and enter to win:
>>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-devel mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>
>>>>>>>                
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>> lucky parental unit.  See the prize list and enter to win:
>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>
>>>>>>
>>>>>>              
>>>>> --
>>>>> Michael Droettboom
>>>>> Science Software Branch
>>>>> Space Telescope Science Institute
>>>>> Baltimore, Maryland, USA
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>> lucky parental unit.  See the prize list and enter to win:
>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>
>>>>>            
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Space Telescope Science Institute
>>>> Baltimore, Maryland, USA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>>          
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Space Telescope Science Institute
>>> Baltimore, Maryland, USA
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>>
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>        
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>      
>
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

On 06/22/2010 06:56 PM, Eric Firing wrote:
>
>> Unfortunately, this fix paves over the exception fixed earlier. Rather
>> than getting an exception when the magnification is too high, it now
>> silently just doesn't draw the image. I'm trying to figure out what the
>> threshold is beyond which it fails in order to manually raise an
>> exception, but not having much luck. I suspect it's somehow related to
>> floating-point or even Agg's fixed-point rounding error.
>>      
> "just doesn't draw" sounds like a pretty benign failure mode.  It might
> even be better than raising an exception.
I was just imagining the frequent questions "my image disappears when I 
zoom in".  I think it's preferable to have an exception (or at least a 
warning) saying something useful in that case.
>   An alternative might be to
> use something like "nonsingular()" to block attempts to make the view
> limits too small--once it is known how to calculate "too small".
Yes.  That's not a bad middle ground between raising an exception and 
doing nothing -- however this only applies to images, so nonsingular() 
or autoscale_view() etc. would have to become aware of when an image was 
on the axes.  Not too difficult, I suppose.
>    Yet
> another alternative, more complicated to implement, would be to clip the
> array and then interpolate to a finer grid at the python level when
> trying to zoom too far into a cell of the original grid.
>    
Yes, perhaps.  But that means reimplementing all of the interpolation 
algorithms we currently use Agg for at the Python level, right?  Doing a 
simple nearest neighbor interpolation in Python and then one of the more 
involved interpolation methods in Agg would not be equivalent.  Such 
effort might be worth it in the long run to support non-regular grids, 
quadmeshes etc., however.  But that's a major project and would probably 
need to be implemented in C/C++ anyway, just not necessarily based on Agg.
> It would be good if everything could be kept at the python or _image.cpp
> level, so that the Agg code could be left unchanged.  As far as I know,
> your previous patch to raise the exception was the only mpl-specific
> change that has been made to the Agg24 code.
>    
There are other changes that have been made over time to keep it 
compatible with newer versions of compilers.  As the upstream of the 
non-GPL version of Agg is basically dead (and AFAICT the GPL'd version 
is too), we're maintaining such changes ourselves.

That said, the pulling of CXX classes into Agg is ugly, but it was the 
quickest solution (and one that will work for Debian as a basic patch 
against matplotlib 0.99.3).  In the long run, the exception should be 
generic as far as Agg is concerned, and try/catch's need to be added 
around all calls into Agg from our Python wrappers.

Mike
> Eric
>
>
>    
>> Mike
>>
>> On 06/22/2010 12:31 PM, Michael Droettboom wrote:
>>      
>>> Ok. Attached is a corrected patch.
>>>
>>> Mike
>>>
>>> On 06/22/2010 12:26 PM, Michael Droettboom wrote:
>>>        
>>>> Hold off, actually. This patch seems to have broken some thing
>>>> inadvertently. Stay tuned...
>>>>
>>>> Mike
>>>>
>>>> On 06/22/2010 12:05 PM, Michael Droettboom wrote:
>>>>          
>>>>> In r8454, I have a applied a fix that allows this C++ exception to
>>>>> correctly percolate to the Python side -- the user will still get an
>>>>> exception, but it will be a Python exception and the interpreter
>>>>> itself does not crash. (It used to work, but recent changes to CXX
>>>>> caused it to break.) I have attached this patch to the e-mail.
>>>>>
>>>>> As Eric suggests, fixing the underlying limitation (I even hesitate
>>>>> to call it a bug because it is definitely a corner case) requires
>>>>> understanding some pretty dark depths of the Agg renderer.
>>>>>
>>>>> Mike
>>>>>
>>>>> On 06/21/2010 10:57 PM, Eric Firing wrote:
>>>>>            
>>>>>> On 06/21/2010 12:24 PM, Sandro Tosi wrote:
>>>>>>              
>>>>>>> forwarded 585442 mat...@li...
>>>>>>> thanks
>>>>>>>
>>>>>>> Hello Matplotlib developers,
>>>>>>> here below is a report a user of maplotlib sent to the Debian bug
>>>>>>> tracker. I've verified and it happend also with 0.99.3:
>>>>>>>
>>>>>>> $ python -c "import matplotlib as p ; print p.__version__"
>>>>>>> 0.99.3
>>>>>>> $ python mpl_crash.py
>>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>>> Aborted
>>>>>>>
>>>>>>> Thanks for looking into it,
>>>>>>> Sandro
>>>>>>>                
>>>>>> Sandro,
>>>>>>
>>>>>> Thanks for reporting it.
>>>>>>
>>>>>> With the default interpolation, rendering gets extremely slow as the
>>>>>> view limits decline to and below a single image pixel. I suspect the
>>>>>> crash is related to this. Neither the slowdown nor the crash occurs
>>>>>> with interpolation='nearest', although there is still an anomaly in
>>>>>> which the image is blank when the viewlim region is too small.
>>>>>>
>>>>>> Like Ryan, I am not familiar with the _image.cpp and the underlying
>>>>>> agg
>>>>>> routines, but I suspect this is going to be a difficult problem to
>>>>>> solve. It may be necessary to put in some workaround, trying to trap
>>>>>> and prevent the extreme slowdown and crash. The slowdown topic came up
>>>>>> on the list years ago.
>>>>>>
>>>>>> http://www.mail-archive.com/mat...@li.../msg00513.html
>>>>>>
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>              
>>>>>>> On Thu, Jun 10, 2010 at 16:52, Teemu Ikonen<tpi...@gm...>
>>>>>>> wrote:
>>>>>>>                
>>>>>>>> Package: python-matplotlib
>>>>>>>> Version: 0.99.1.2-3
>>>>>>>> Severity: important
>>>>>>>>
>>>>>>>> Running a program which displays an image with plt.imshow() and
>>>>>>>> changes the
>>>>>>>> axes with plt.axis() before calling plt.show() crashes the python
>>>>>>>> interpreter:
>>>>>>>>
>>>>>>>> $ python mpl_crash.py
>>>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>>>> Aborted
>>>>>>>>
>>>>>>>> This happens at least with Qt4Agg, GTKAgg and TKAgg backends.
>>>>>>>>
>>>>>>>> The example program is attached.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Teemu
>>>>>>>>
>>>>>>>> -- System Information:
>>>>>>>> Debian Release: squeeze/sid
>>>>>>>> APT prefers testing
>>>>>>>> APT policy: (500, 'testing')
>>>>>>>> Architecture: amd64 (x86_64)
>>>>>>>>
>>>>>>>> Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
>>>>>>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>>>>>>> Shell: /bin/sh linked to /bin/dash
>>>>>>>>
>>>>>>>> Versions of packages python-matplotlib depends on:
>>>>>>>> ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
>>>>>>>> ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
>>>>>>>> ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra
>>>>>>>> ii libfontconfig1 2.8.0-2.1 generic font configuration library
>>>>>>>> ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib
>>>>>>>> ii libgcc1 1:4.4.4-1 GCC support library
>>>>>>>> ii libglib2.0-0 2.24.1-1 The GLib library of C routines
>>>>>>>> ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface
>>>>>>>> ii libpango1.0-0 1.28.0-1 Layout and rendering of internatio
>>>>>>>> ii libpng12-0 1.2.43-1 PNG library - runtime
>>>>>>>> ii libstdc++6 4.4.4-1 The GNU Standard C++ Library v3
>>>>>>>> ii python 2.5.4-9 An interactive high-level object-o
>>>>>>>> ii python-cairo 1.8.8-1+b1 Python bindings for the Cairo vect
>>>>>>>> ii python-dateutil 1.4.1-3 powerful extensions to the standar
>>>>>>>> ii python-gobject 2.21.1-1 Python bindings for the GObject li
>>>>>>>> ii python-matplotlib-data 0.99.1.2-3 Python based plotting system
>>>>>>>> (data
>>>>>>>> ii python-numpy 1:1.3.0-3+b1 Numerical Python adds a fast array
>>>>>>>> ii python-pyparsing 1.5.2-2 Python parsing module
>>>>>>>> ii python-support 1.0.8 automated rebuilding support for P
>>>>>>>> ii python-tz 2010b-1 Python version of the Olson timezo
>>>>>>>> ii tcl8.5 8.5.8-2 Tcl (the Tool Command Language) v8
>>>>>>>> ii tk8.5 8.5.8-1 Tk toolkit for Tcl and X11, v8.5 -
>>>>>>>> ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
>>>>>>>>
>>>>>>>> Versions of packages python-matplotlib recommends:
>>>>>>>> ii python-glade2 2.17.0-2 GTK+ bindings: Glade support
>>>>>>>> ii python-tk 2.6.5-1 Tkinter - Writing Tk applications
>>>>>>>>
>>>>>>>> Versions of packages python-matplotlib suggests:
>>>>>>>> ii dvipng 1.13-1 convert DVI files to PNG graphics
>>>>>>>> ii ipython 0.10-2 enhanced interactive Python shell
>>>>>>>> ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG
>>>>>>>> ii python-configobj 4.7.2+ds-1 simple but powerful config file re
>>>>>>>> pn python-excelerator<none>  (no description available)
>>>>>>>> ii python-gtk2 2.17.0-2 Python bindings for the GTK+ widge
>>>>>>>> pn python-matplotlib-doc<none>  (no description available)
>>>>>>>> pn python-qt3<none>  (no description available)
>>>>>>>> ii python-qt4 4.7.3-1 Python bindings for Qt4
>>>>>>>> ii python-scipy 0.7.2-1 scientific tools for Python
>>>>>>>> ii python-traits 3.3.0-1 Manifest typing and reactive progr
>>>>>>>> ii python-wxgtk2.8 2.8.10.1-3 wxWidgets Cross-platform C++ GUI t
>>>>>>>> ii texlive-extra-utils 2009-7 TeX Live: TeX auxiliary programs
>>>>>>>> ii texlive-latex-extra 2009-7 TeX Live: LaTeX supplementary pack
>>>>>>>>
>>>>>>>> -- no debconf information
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Python-modules-team mailing list
>>>>>>>> Pyt...@li...
>>>>>>>> http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
>>>>>>>>
>>>>>>>>                  
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>>
>>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>>> lucky parental unit. See the prize list and enter to win:
>>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Matplotlib-devel mailing list
>>>>>>> Mat...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>>                
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>> lucky parental unit. See the prize list and enter to win:
>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>>              
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>> lucky parental unit.  See the prize list and enter to win:
>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>            
>>>>
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Space Telescope Science Institute
>>>> Baltimore, Maryland, USA
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>          
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Space Telescope Science Institute
>>> Baltimore, Maryland, USA
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>        
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>> Baltimore, Maryland, USA
>>
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>>
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>      
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Eric,

I should have left more comments about my change.
The issue is that the current slicing algorithm sometimes fails with
"_draw_unsampled_image" which support arbitrary affine transformation
of the image. The slicing gets wrong when the image is significantly
skewed or rotated. So, as a temporary measure, I simply wanted to
disable the slicing until we have a correct algorithm in place.

I guess a quick (still temporary) fix is to check if affine transform
is needed, and do the slicing if not.
Something like below. The condition is not exactly correct, but I
think it would work in most of cases.
I actually didn't test the patch. I'll be out of town until the end of
this week.

On a second thought, I think it should not be difficult to workaround
the slicing thing for arbitrary affine transform. I'll think about the
whole issue again when I get back. If you have a better idea, please
go ahead and implement.

Regards,

-JJ

diff --git a/lib/matplotlib/image.py b/lib/matplotlib/image.py
index 7c1128f..b65f446 100644
--- a/lib/matplotlib/image.py
+++ b/lib/matplotlib/image.py
@@ -248,9 +248,14 @@ class _AxesImageBase(martist.Artist, cm.ScalarMappable):
         """


+        if self._image_skew_coordinate:
+            no_slice = True
+        else:
+            no_slice = False
+
         im, xmin, ymin, dxintv, dyintv, sx, sy = \
             self._get_unsampled_image(self._A, self.get_extent(),
-                                      self.axes.viewLim, noslice=True)
+                                      self.axes.viewLim, noslice=no_slice)

         if im is None: return # I'm not if this check is required. -JJL



On Tue, Jun 22, 2010 at 8:45 PM, Eric Firing <ef...@ha...> wrote:
> JJ,
>
> In AxesImageBase._draw_unsampled_image, there is a call to
> _get_unsampled_image(...noslice=True).  When using imshow(Z,
> interpolation='nearest'), this defeats the slicing that makes such a
> difference when zooming and panning a small chunk of a large image. Changing
> it to False makes imshow work better; I don't understand why one would ever
> want noslice=True.  Am I missing something?  Can we just change it to False?
>  Or remove the noslice option and kwarg entirely?
>
> Eric
>

JJ,

In AxesImageBase._draw_unsampled_image, there is a call to 
_get_unsampled_image(...noslice=True).  When using imshow(Z, 
interpolation='nearest'), this defeats the slicing that makes such a 
difference when zooming and panning a small chunk of a large image. 
Changing it to False makes imshow work better; I don't understand why 
one would ever want noslice=True.  Am I missing something?  Can we just 
change it to False?  Or remove the noslice option and kwarg entirely?

Eric

On 06/22/2010 10:11 AM, Michael Droettboom wrote:
> SVN r8456 has a patch for the slowness Eric described when doing extreme
> magnification on an image.

Excellent!

>
> Unfortunately, this fix paves over the exception fixed earlier. Rather
> than getting an exception when the magnification is too high, it now
> silently just doesn't draw the image. I'm trying to figure out what the
> threshold is beyond which it fails in order to manually raise an
> exception, but not having much luck. I suspect it's somehow related to
> floating-point or even Agg's fixed-point rounding error.

"just doesn't draw" sounds like a pretty benign failure mode.  It might 
even be better than raising an exception.  An alternative might be to 
use something like "nonsingular()" to block attempts to make the view 
limits too small--once it is known how to calculate "too small".  Yet 
another alternative, more complicated to implement, would be to clip the 
array and then interpolate to a finer grid at the python level when 
trying to zoom too far into a cell of the original grid.

It would be good if everything could be kept at the python or _image.cpp 
level, so that the Agg code could be left unchanged.  As far as I know, 
your previous patch to raise the exception was the only mpl-specific 
change that has been made to the Agg24 code.

Eric


>
> Mike
>
> On 06/22/2010 12:31 PM, Michael Droettboom wrote:
>> Ok. Attached is a corrected patch.
>>
>> Mike
>>
>> On 06/22/2010 12:26 PM, Michael Droettboom wrote:
>>> Hold off, actually. This patch seems to have broken some thing
>>> inadvertently. Stay tuned...
>>>
>>> Mike
>>>
>>> On 06/22/2010 12:05 PM, Michael Droettboom wrote:
>>>> In r8454, I have a applied a fix that allows this C++ exception to
>>>> correctly percolate to the Python side -- the user will still get an
>>>> exception, but it will be a Python exception and the interpreter
>>>> itself does not crash. (It used to work, but recent changes to CXX
>>>> caused it to break.) I have attached this patch to the e-mail.
>>>>
>>>> As Eric suggests, fixing the underlying limitation (I even hesitate
>>>> to call it a bug because it is definitely a corner case) requires
>>>> understanding some pretty dark depths of the Agg renderer.
>>>>
>>>> Mike
>>>>
>>>> On 06/21/2010 10:57 PM, Eric Firing wrote:
>>>>> On 06/21/2010 12:24 PM, Sandro Tosi wrote:
>>>>>> forwarded 585442 mat...@li...
>>>>>> thanks
>>>>>>
>>>>>> Hello Matplotlib developers,
>>>>>> here below is a report a user of maplotlib sent to the Debian bug
>>>>>> tracker. I've verified and it happend also with 0.99.3:
>>>>>>
>>>>>> $ python -c "import matplotlib as p ; print p.__version__"
>>>>>> 0.99.3
>>>>>> $ python mpl_crash.py
>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>> Aborted
>>>>>>
>>>>>> Thanks for looking into it,
>>>>>> Sandro
>>>>> Sandro,
>>>>>
>>>>> Thanks for reporting it.
>>>>>
>>>>> With the default interpolation, rendering gets extremely slow as the
>>>>> view limits decline to and below a single image pixel. I suspect the
>>>>> crash is related to this. Neither the slowdown nor the crash occurs
>>>>> with interpolation='nearest', although there is still an anomaly in
>>>>> which the image is blank when the viewlim region is too small.
>>>>>
>>>>> Like Ryan, I am not familiar with the _image.cpp and the underlying
>>>>> agg
>>>>> routines, but I suspect this is going to be a difficult problem to
>>>>> solve. It may be necessary to put in some workaround, trying to trap
>>>>> and prevent the extreme slowdown and crash. The slowdown topic came up
>>>>> on the list years ago.
>>>>>
>>>>> http://www.mail-archive.com/mat...@li.../msg00513.html
>>>>>
>>>>>
>>>>> Eric
>>>>>
>>>>>> On Thu, Jun 10, 2010 at 16:52, Teemu Ikonen<tpi...@gm...>
>>>>>> wrote:
>>>>>>> Package: python-matplotlib
>>>>>>> Version: 0.99.1.2-3
>>>>>>> Severity: important
>>>>>>>
>>>>>>> Running a program which displays an image with plt.imshow() and
>>>>>>> changes the
>>>>>>> axes with plt.axis() before calling plt.show() crashes the python
>>>>>>> interpreter:
>>>>>>>
>>>>>>> $ python mpl_crash.py
>>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>>> Aborted
>>>>>>>
>>>>>>> This happens at least with Qt4Agg, GTKAgg and TKAgg backends.
>>>>>>>
>>>>>>> The example program is attached.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Teemu
>>>>>>>
>>>>>>> -- System Information:
>>>>>>> Debian Release: squeeze/sid
>>>>>>> APT prefers testing
>>>>>>> APT policy: (500, 'testing')
>>>>>>> Architecture: amd64 (x86_64)
>>>>>>>
>>>>>>> Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
>>>>>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>>>>>> Shell: /bin/sh linked to /bin/dash
>>>>>>>
>>>>>>> Versions of packages python-matplotlib depends on:
>>>>>>> ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
>>>>>>> ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib
>>>>>>> ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra
>>>>>>> ii libfontconfig1 2.8.0-2.1 generic font configuration library
>>>>>>> ii libfreetype6 2.3.11-1 FreeType 2 font engine, shared lib
>>>>>>> ii libgcc1 1:4.4.4-1 GCC support library
>>>>>>> ii libglib2.0-0 2.24.1-1 The GLib library of C routines
>>>>>>> ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface
>>>>>>> ii libpango1.0-0 1.28.0-1 Layout and rendering of internatio
>>>>>>> ii libpng12-0 1.2.43-1 PNG library - runtime
>>>>>>> ii libstdc++6 4.4.4-1 The GNU Standard C++ Library v3
>>>>>>> ii python 2.5.4-9 An interactive high-level object-o
>>>>>>> ii python-cairo 1.8.8-1+b1 Python bindings for the Cairo vect
>>>>>>> ii python-dateutil 1.4.1-3 powerful extensions to the standar
>>>>>>> ii python-gobject 2.21.1-1 Python bindings for the GObject li
>>>>>>> ii python-matplotlib-data 0.99.1.2-3 Python based plotting system
>>>>>>> (data
>>>>>>> ii python-numpy 1:1.3.0-3+b1 Numerical Python adds a fast array
>>>>>>> ii python-pyparsing 1.5.2-2 Python parsing module
>>>>>>> ii python-support 1.0.8 automated rebuilding support for P
>>>>>>> ii python-tz 2010b-1 Python version of the Olson timezo
>>>>>>> ii tcl8.5 8.5.8-2 Tcl (the Tool Command Language) v8
>>>>>>> ii tk8.5 8.5.8-1 Tk toolkit for Tcl and X11, v8.5 -
>>>>>>> ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
>>>>>>>
>>>>>>> Versions of packages python-matplotlib recommends:
>>>>>>> ii python-glade2 2.17.0-2 GTK+ bindings: Glade support
>>>>>>> ii python-tk 2.6.5-1 Tkinter - Writing Tk applications
>>>>>>>
>>>>>>> Versions of packages python-matplotlib suggests:
>>>>>>> ii dvipng 1.13-1 convert DVI files to PNG graphics
>>>>>>> ii ipython 0.10-2 enhanced interactive Python shell
>>>>>>> ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG
>>>>>>> ii python-configobj 4.7.2+ds-1 simple but powerful config file re
>>>>>>> pn python-excelerator<none> (no description available)
>>>>>>> ii python-gtk2 2.17.0-2 Python bindings for the GTK+ widge
>>>>>>> pn python-matplotlib-doc<none> (no description available)
>>>>>>> pn python-qt3<none> (no description available)
>>>>>>> ii python-qt4 4.7.3-1 Python bindings for Qt4
>>>>>>> ii python-scipy 0.7.2-1 scientific tools for Python
>>>>>>> ii python-traits 3.3.0-1 Manifest typing and reactive progr
>>>>>>> ii python-wxgtk2.8 2.8.10.1-3 wxWidgets Cross-platform C++ GUI t
>>>>>>> ii texlive-extra-utils 2009-7 TeX Live: TeX auxiliary programs
>>>>>>> ii texlive-latex-extra 2009-7 TeX Live: LaTeX supplementary pack
>>>>>>>
>>>>>>> -- no debconf information
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Python-modules-team mailing list
>>>>>>> Pyt...@li...
>>>>>>> http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>>> lucky parental unit. See the prize list and enter to win:
>>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>> lucky parental unit. See the prize list and enter to win:
>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>
>>>>
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Space Telescope Science Institute
>>> Baltimore, Maryland, USA
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>> Baltimore, Maryland, USA
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>
>
> --
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
>
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

SVN r8456 has a patch for the slowness Eric described when doing extreme 
magnification on an image.

Unfortunately, this fix paves over the exception fixed earlier.  Rather 
than getting an exception when the magnification is too high, it now 
silently just doesn't draw the image.  I'm trying to figure out what the 
threshold is beyond which it fails in order to manually raise an 
exception, but not having much luck.  I suspect it's somehow related to 
floating-point or even Agg's fixed-point rounding error.

Mike

On 06/22/2010 12:31 PM, Michael Droettboom wrote:
> Ok.  Attached is a corrected patch.
>
> Mike
>
> On 06/22/2010 12:26 PM, Michael Droettboom wrote:
>> Hold off, actually.  This patch seems to have broken some thing 
>> inadvertently.  Stay tuned...
>>
>> Mike
>>
>> On 06/22/2010 12:05 PM, Michael Droettboom wrote:
>>> In r8454, I have a applied a fix that allows this C++ exception to 
>>> correctly percolate to the Python side -- the user will still get an 
>>> exception, but it will be a Python exception and the interpreter 
>>> itself does not crash.   (It used to work, but recent changes to CXX 
>>> caused it to break.)  I have attached this patch to the e-mail.
>>>
>>> As Eric suggests, fixing the underlying limitation (I even hesitate 
>>> to call it a bug because it is definitely a corner case) requires 
>>> understanding some pretty dark depths of the Agg renderer.
>>>
>>> Mike
>>>
>>> On 06/21/2010 10:57 PM, Eric Firing wrote:
>>>> On 06/21/2010 12:24 PM, Sandro Tosi wrote:
>>>>> forwarded 585442 mat...@li...
>>>>> thanks
>>>>>
>>>>> Hello Matplotlib developers,
>>>>> here below is a report a user of maplotlib sent to the Debian bug
>>>>> tracker. I've verified and it happend also with 0.99.3:
>>>>>
>>>>> $ python -c "import matplotlib as p ; print p.__version__"
>>>>> 0.99.3
>>>>> $ python mpl_crash.py
>>>>> terminate called after throwing an instance of 'char const*'
>>>>> Aborted
>>>>>
>>>>> Thanks for looking into it,
>>>>> Sandro
>>>> Sandro,
>>>>
>>>> Thanks for reporting it.
>>>>
>>>> With the default interpolation, rendering gets extremely slow as the
>>>> view limits decline to and below a single image pixel.  I suspect the
>>>> crash is related to this.  Neither the slowdown nor the crash occurs
>>>> with interpolation='nearest', although there is still an anomaly in
>>>> which the image is blank when the viewlim region is too small.
>>>>
>>>> Like Ryan, I am not familiar with the _image.cpp and the underlying 
>>>> agg
>>>> routines, but I suspect this is going to be a difficult problem to
>>>> solve.  It may be necessary to put in some workaround, trying to trap
>>>> and prevent the extreme slowdown and crash.  The slowdown topic 
>>>> came up
>>>> on the list years ago.
>>>>
>>>> http://www.mail-archive.com/mat...@li.../msg00513.html 
>>>>
>>>>
>>>> Eric
>>>>
>>>>> On Thu, Jun 10, 2010 at 16:52, Teemu Ikonen<tpi...@gm...>   
>>>>> wrote:
>>>>>> Package: python-matplotlib
>>>>>> Version: 0.99.1.2-3
>>>>>> Severity: important
>>>>>>
>>>>>> Running a program which displays an image with plt.imshow() and 
>>>>>> changes the
>>>>>> axes with plt.axis() before calling plt.show() crashes the python 
>>>>>> interpreter:
>>>>>>
>>>>>> $ python mpl_crash.py
>>>>>> terminate called after throwing an instance of 'char const*'
>>>>>> Aborted
>>>>>>
>>>>>> This happens at least with Qt4Agg, GTKAgg and TKAgg backends.
>>>>>>
>>>>>> The example program is attached.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Teemu
>>>>>>
>>>>>> -- System Information:
>>>>>> Debian Release: squeeze/sid
>>>>>>    APT prefers testing
>>>>>>    APT policy: (500, 'testing')
>>>>>> Architecture: amd64 (x86_64)
>>>>>>
>>>>>> Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores)
>>>>>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>>>>>> Shell: /bin/sh linked to /bin/dash
>>>>>>
>>>>>> Versions of packages python-matplotlib depends on:
>>>>>> ii  libatk1.0-0             1.30.0-1         The ATK 
>>>>>> accessibility toolkit
>>>>>> ii  libc6                   2.10.2-9         Embedded GNU C 
>>>>>> Library: Shared lib
>>>>>> ii  libcairo2               1.8.10-4         The Cairo 2D vector 
>>>>>> graphics libra
>>>>>> ii  libfontconfig1          2.8.0-2.1        generic font 
>>>>>> configuration library
>>>>>> ii  libfreetype6            2.3.11-1         FreeType 2 font 
>>>>>> engine, shared lib
>>>>>> ii  libgcc1                 1:4.4.4-1        GCC support library
>>>>>> ii  libglib2.0-0            2.24.1-1         The GLib library of 
>>>>>> C routines
>>>>>> ii  libgtk2.0-0             2.20.1-1         The GTK+ graphical 
>>>>>> user interface
>>>>>> ii  libpango1.0-0           1.28.0-1         Layout and rendering 
>>>>>> of internatio
>>>>>> ii  libpng12-0              1.2.43-1         PNG library - runtime
>>>>>> ii  libstdc++6              4.4.4-1          The GNU Standard C++ 
>>>>>> Library v3
>>>>>> ii  python                  2.5.4-9          An interactive 
>>>>>> high-level object-o
>>>>>> ii  python-cairo            1.8.8-1+b1       Python bindings for 
>>>>>> the Cairo vect
>>>>>> ii  python-dateutil         1.4.1-3          powerful extensions 
>>>>>> to the standar
>>>>>> ii  python-gobject          2.21.1-1         Python bindings for 
>>>>>> the GObject li
>>>>>> ii  python-matplotlib-data  0.99.1.2-3       Python based 
>>>>>> plotting system (data
>>>>>> ii  python-numpy            1:1.3.0-3+b1     Numerical Python 
>>>>>> adds a fast array
>>>>>> ii  python-pyparsing        1.5.2-2          Python parsing module
>>>>>> ii  python-support          1.0.8            automated rebuilding 
>>>>>> support for P
>>>>>> ii  python-tz               2010b-1          Python version of 
>>>>>> the Olson timezo
>>>>>> ii  tcl8.5                  8.5.8-2          Tcl (the Tool 
>>>>>> Command Language) v8
>>>>>> ii  tk8.5                   8.5.8-1          Tk toolkit for Tcl 
>>>>>> and X11, v8.5 -
>>>>>> ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library 
>>>>>> - runtime
>>>>>>
>>>>>> Versions of packages python-matplotlib recommends:
>>>>>> ii  python-glade2                 2.17.0-2   GTK+ bindings: Glade 
>>>>>> support
>>>>>> ii  python-tk                     2.6.5-1    Tkinter - Writing Tk 
>>>>>> applications
>>>>>>
>>>>>> Versions of packages python-matplotlib suggests:
>>>>>> ii  dvipng                        1.13-1     convert DVI files to 
>>>>>> PNG graphics
>>>>>> ii  ipython                       0.10-2     enhanced interactive 
>>>>>> Python shell
>>>>>> ii  librsvg2-common               2.26.3-1   SAX-based renderer 
>>>>>> library for SVG
>>>>>> ii  python-configobj              4.7.2+ds-1 simple but powerful 
>>>>>> config file re
>>>>>> pn  python-excelerator<none>        (no description available)
>>>>>> ii  python-gtk2                   2.17.0-2   Python bindings for 
>>>>>> the GTK+ widge
>>>>>> pn  python-matplotlib-doc<none>        (no description available)
>>>>>> pn  python-qt3<none>        (no description available)
>>>>>> ii  python-qt4                    4.7.3-1    Python bindings for Qt4
>>>>>> ii  python-scipy                  0.7.2-1    scientific tools for 
>>>>>> Python
>>>>>> ii  python-traits                 3.3.0-1    Manifest typing and 
>>>>>> reactive progr
>>>>>> ii  python-wxgtk2.8               2.8.10.1-3 wxWidgets 
>>>>>> Cross-platform C++ GUI t
>>>>>> ii  texlive-extra-utils           2009-7     TeX Live: TeX 
>>>>>> auxiliary programs
>>>>>> ii  texlive-latex-extra           2009-7     TeX Live: LaTeX 
>>>>>> supplementary pack
>>>>>>
>>>>>> -- no debconf information
>>>>>>
>>>>>> _______________________________________________
>>>>>> Python-modules-team mailing list
>>>>>> Pyt...@li...
>>>>>> http://lists.alioth.debian.org/mailman/listinfo/python-modules-team
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------ 
>>>>>
>>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>>> lucky parental unit.  See the prize list and enter to win:
>>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>> ------------------------------------------------------------------------------ 
>>>>
>>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>>> lucky parental unit.  See the prize list and enter to win:
>>>> http://p.sf.net/sfu/thinkgeek-promo
>>>> _______________________________________________
>>>> Matplotlib-devel mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>>> lucky parental unit.  See the prize list and enter to win:
>>> http://p.sf.net/sfu/thinkgeek-promo
>>>
>>>
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>    
>>
>>
>> -- 
>> Michael Droettboom
>> Science Software Branch
>> Space Telescope Science Institute
>> Baltimore, Maryland, USA
>>
>>
>> ------------------------------------------------------------------------------
>> ThinkGeek and WIRED's GeekDad team up for the Ultimate
>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
>> lucky parental unit.  See the prize list and enter to win:
>> http://p.sf.net/sfu/thinkgeek-promo
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>    
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Space Telescope Science Institute
> Baltimore, Maryland, USA
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>    


-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA