matplotlib-devel Mailing List for matplotlib

Oops, sorry, that'll teach me to check more than just the last diff!

Ben

On Sat, Jul 3, 2010 at 2:11 PM, Eric Firing <ef...@ha...> wrote:

> On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:
> > Do we want to add a note to the CHANGELOG for this?
>
> I did.
>
> Eric
>
> >
> > Ben Root
> >
> > On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing <ef...@ha...>
> > wrote:
> >
> >         On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
> >         > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing
> >         <ef...@ha...> wrote:
> >         > > On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
> >         > >> My understanding is that the proposed change will break
> >         at least some
> >         > >> existing code, hence my proposal to go the safer route.
> >         > >
> >         > > On what is that understanding based?  Any actual examples
> >         or use cases?
> >         > >
> >         > > I think the only such cases would be interactive scripts.
> >          One can
> >         > > imagine a script in which a plot is made, the user views
> >         it, perhaps
> >         > > uses a gui to change the limits, then presses a button to
> >         plot the next
> >         > > data set on top of the first, expecting that it will again
> >         autoscale,
> >         > > and so forth.  Maybe this is sufficient justification for
> >         leaving the
> >         > > present version alone.  That is what I am trying to find
> >         out.  In
> >         > > addition, the change would require scanning the internal
> >         mpl code to see
> >         > > whether there are uses of set_xlim that would have to be
> >         changed.
> >         >
> >         > The points you make are exactly what I was thinking about.
> >         > A subtle alteration of the behaviour of matplotlib caused by
> >         the
> >         > change is the worse case scenario, because it might not be
> >         > straightforward to detect/correct.
> >         > I also have a number of matplotlib interactive scripts /GUIs
> >         used in
> >         > production. Most rely on precise control of the viewing area
> >         and some
> >         > will be affected by the change.
> >         >
> >         > >
> >         > >>
> >         > >> Also I'm unconvinced by the justification for the
> >         change :
> >         > >> xlim and autoscalex_on are independant attributes, why
> >         then should setting
> >         > >
> >         > > They are not independent, they are potentially in
> >         conflict--two
> >         > > mechanisms fighting for control of the axis.
> >         > >
> >         > >> xlim have the side effect of turning autoscalex off ?
> >         This is not consistent
> >         > >> with how the API works. If I really wanted autoscalex
> >         off, I would have
> >         > >> specified it.
> >         > >
> >         > > The idea of having interactive plotting commands is to
> >         make the
> >         > > interaction easy and natural.  When you call set_xlim
> >         interactively, it
> >         > > is because that is what you want the limits to be.  At
> >         least that point
> >         > > of view has been expressed several times on the lists.  I
> >         have yet to
> >         > > hear someone say, "I rely on the present behavior".  In
> >         scripts, when
> >         > > there is no interactive scenario such as I described in
> >         the previous
> >         > > paragraph, the problem with the present behavior is that
> >         it means
> >         > > set_xlim has no effect at all if followed by a plot
> >         command unless one
> >         > > has disabled autoscaling either via a kwarg in the plot
> >         command, or via
> >         > > ax.set_autoscalex_on(False).  The latter is just plain
> >         ugly, to my eye.
> >         >
> >         > My personal opinion is that the current behaviour is not
> >         broken.
> >         > When typing commands interactively in pylab or writing a
> >         regular
> >         > script it can be frustrating. But in interactive GUIs it is
> >         useful to
> >         > have full independent control over the two parameters.
> >         > In most cases I agree that the proposed behaviour is what
> >         the user
> >         > wants. But this is not true in all cases.
> >         >
> >         > >> To sum things up:
> >         > >> Adding an argument to set_xlim to allow autoscale to be
> >         turned off in the
> >         > >> same step would be a good idea. But it shouldn't suddenly
> >         become the default
> >         > >> behaviour.
> >         > >
> >         > > You may well be right about this.  In any case, I suspect
> >         no change will
> >         > > occur prior to the 1.0 release.
> >         > >
> >         > > Additional perspective: the behavior of Matlab's xlim is
> >         as I have
> >         > > proposed, not as mpl xlim presently works.  I don't
> >         believe in following
> >         > > Matlab slavishly--sometimes we can make better choices
> >         than Matlab
> >         > > has--but I think that this is a case where Matlab got it
> >         right and we
> >         > > did not, the first time around.  This may be because the
> >         _autoscalex and
> >         > > _autoscaley attributes were added to the mpl Axes long
> >         after set_xlim.
> >         >
> >         > As the change of default behaviour seems to be going ahead,
> >         I must
> >         > request the addition of an new argument to xlim
> >         (autoscalex=False).
> >         > The purpose being to allow the user to modify his code to
> >         retain the
> >         > current behaviour when desired.
> >
> >
> >         I made two commits, 8479 and 8480.  Other developers are
> >         welcome to
> >         revert them or modify them as needed.  Certainly they need
> >         testing and
> >         review, the more, the better.  I had to change quite a few
> >         things, so
> >         there is risk, as you note.  I am a bit concerned about
> >         whether enough
> >         people will be able to do enough testing of this before
> >         release to shake
> >         out any bugs.
> >
> >         The new kwarg for set_xlim and set_ylim is simply "auto"; set
> >         it to None
> >         to obtain the old behavior:
> >
> >                  *auto*: [ True | False | None ]
> >                    turn *x* autoscaling on (True), off (False;
> >         default),
> >                    or leave unchanged (None)
> >
> >         set_xbound retains the old behavior, by calling set_xlim with
> >         auto=None.
> >
> >         We have several options at present.  If the changes I made are
> >         junk,
> >         they can be discarded, or deferred until more time is
> >         available for
> >         testing and reworking.  If they are basically sound but too
> >         abrupt, then
> >         the default could be changed to auto=None, with the
> >         possibility of
> >         shifting it later.  Additionally, an rcparam could be used,
> >         although I
> >         don't like making ever more rcparams.
> >
> >         In addition to the changes to set_xlim, I tried to clarify the
> >         documentation, and I added an "autoscale" convenience method
> >         and pyplot
> >         function, which I think was needed.
> >
> >         One more change I would like to see is the simple and, I
> >         think, safe one
> >         of supporting descriptive kwarg names alongside the present
> >         misleading
> >         ones: e.g. for xlim, "left" would be equivalent to "xmin",
> >         etc.
> >
> >
> >         I am on a ship until July 5, working with a high-latency
> >         internet
> >         connection through an intermediate machine, and I can't afford
> >         much more
> >         time on this while I am out here. (And working with svn from
> >         here is
> >         pretty cumbersome.)
> >
> >         Eric
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >         This SF.net email is sponsored by Sprint
> >         What will you do first with EVO, the first 4G phone?
> >         Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> >         _______________________________________________
> >         Matplotlib-devel mailing list
> >         Mat...@li...
> >         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by Sprint
> > What will you do first with EVO, the first 4G phone?
> > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> > _______________________________________________ Matplotlib-devel mailing
> list Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>

On Sat, 2010-07-03 at 09:13 -0500, Benjamin Root wrote:
> Do we want to add a note to the CHANGELOG for this?

I did.

Eric

> 
> Ben Root
> 
> On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing <ef...@ha...>
> wrote:
>         
>         On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
>         > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing
>         <ef...@ha...> wrote:
>         > > On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
>         > >> My understanding is that the proposed change will break
>         at least some
>         > >> existing code, hence my proposal to go the safer route.
>         > >
>         > > On what is that understanding based?  Any actual examples
>         or use cases?
>         > >
>         > > I think the only such cases would be interactive scripts.
>          One can
>         > > imagine a script in which a plot is made, the user views
>         it, perhaps
>         > > uses a gui to change the limits, then presses a button to
>         plot the next
>         > > data set on top of the first, expecting that it will again
>         autoscale,
>         > > and so forth.  Maybe this is sufficient justification for
>         leaving the
>         > > present version alone.  That is what I am trying to find
>         out.  In
>         > > addition, the change would require scanning the internal
>         mpl code to see
>         > > whether there are uses of set_xlim that would have to be
>         changed.
>         >
>         > The points you make are exactly what I was thinking about.
>         > A subtle alteration of the behaviour of matplotlib caused by
>         the
>         > change is the worse case scenario, because it might not be
>         > straightforward to detect/correct.
>         > I also have a number of matplotlib interactive scripts /GUIs
>         used in
>         > production. Most rely on precise control of the viewing area
>         and some
>         > will be affected by the change.
>         >
>         > >
>         > >>
>         > >> Also I'm unconvinced by the justification for the
>         change :
>         > >> xlim and autoscalex_on are independant attributes, why
>         then should setting
>         > >
>         > > They are not independent, they are potentially in
>         conflict--two
>         > > mechanisms fighting for control of the axis.
>         > >
>         > >> xlim have the side effect of turning autoscalex off ?
>         This is not consistent
>         > >> with how the API works. If I really wanted autoscalex
>         off, I would have
>         > >> specified it.
>         > >
>         > > The idea of having interactive plotting commands is to
>         make the
>         > > interaction easy and natural.  When you call set_xlim
>         interactively, it
>         > > is because that is what you want the limits to be.  At
>         least that point
>         > > of view has been expressed several times on the lists.  I
>         have yet to
>         > > hear someone say, "I rely on the present behavior".  In
>         scripts, when
>         > > there is no interactive scenario such as I described in
>         the previous
>         > > paragraph, the problem with the present behavior is that
>         it means
>         > > set_xlim has no effect at all if followed by a plot
>         command unless one
>         > > has disabled autoscaling either via a kwarg in the plot
>         command, or via
>         > > ax.set_autoscalex_on(False).  The latter is just plain
>         ugly, to my eye.
>         >
>         > My personal opinion is that the current behaviour is not
>         broken.
>         > When typing commands interactively in pylab or writing a
>         regular
>         > script it can be frustrating. But in interactive GUIs it is
>         useful to
>         > have full independent control over the two parameters.
>         > In most cases I agree that the proposed behaviour is what
>         the user
>         > wants. But this is not true in all cases.
>         >
>         > >> To sum things up:
>         > >> Adding an argument to set_xlim to allow autoscale to be
>         turned off in the
>         > >> same step would be a good idea. But it shouldn't suddenly
>         become the default
>         > >> behaviour.
>         > >
>         > > You may well be right about this.  In any case, I suspect
>         no change will
>         > > occur prior to the 1.0 release.
>         > >
>         > > Additional perspective: the behavior of Matlab's xlim is
>         as I have
>         > > proposed, not as mpl xlim presently works.  I don't
>         believe in following
>         > > Matlab slavishly--sometimes we can make better choices
>         than Matlab
>         > > has--but I think that this is a case where Matlab got it
>         right and we
>         > > did not, the first time around.  This may be because the
>         _autoscalex and
>         > > _autoscaley attributes were added to the mpl Axes long
>         after set_xlim.
>         >
>         > As the change of default behaviour seems to be going ahead,
>         I must
>         > request the addition of an new argument to xlim
>         (autoscalex=False).
>         > The purpose being to allow the user to modify his code to
>         retain the
>         > current behaviour when desired.
>         
>         
>         I made two commits, 8479 and 8480.  Other developers are
>         welcome to
>         revert them or modify them as needed.  Certainly they need
>         testing and
>         review, the more, the better.  I had to change quite a few
>         things, so
>         there is risk, as you note.  I am a bit concerned about
>         whether enough
>         people will be able to do enough testing of this before
>         release to shake
>         out any bugs.
>         
>         The new kwarg for set_xlim and set_ylim is simply "auto"; set
>         it to None
>         to obtain the old behavior:
>         
>                  *auto*: [ True | False | None ]
>                    turn *x* autoscaling on (True), off (False;
>         default),
>                    or leave unchanged (None)
>         
>         set_xbound retains the old behavior, by calling set_xlim with
>         auto=None.
>         
>         We have several options at present.  If the changes I made are
>         junk,
>         they can be discarded, or deferred until more time is
>         available for
>         testing and reworking.  If they are basically sound but too
>         abrupt, then
>         the default could be changed to auto=None, with the
>         possibility of
>         shifting it later.  Additionally, an rcparam could be used,
>         although I
>         don't like making ever more rcparams.
>         
>         In addition to the changes to set_xlim, I tried to clarify the
>         documentation, and I added an "autoscale" convenience method
>         and pyplot
>         function, which I think was needed.
>         
>         One more change I would like to see is the simple and, I
>         think, safe one
>         of supporting descriptive kwarg names alongside the present
>         misleading
>         ones: e.g. for xlim, "left" would be equivalent to "xmin",
>         etc.
>         
>         
>         I am on a ship until July 5, working with a high-latency
>         internet
>         connection through an intermediate machine, and I can't afford
>         much more
>         time on this while I am out here. (And working with svn from
>         here is
>         pretty cumbersome.)
>         
>         Eric
>         
>         
>         
>         
>         ------------------------------------------------------------------------------
>         This SF.net email is sponsored by Sprint
>         What will you do first with EVO, the first 4G phone?
>         Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>         _______________________________________________
>         Matplotlib-devel mailing list
>         Mat...@li...
>         https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>         
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________ Matplotlib-devel mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Jul 3, 2010 at 1:11 AM, Ryan May <rm...@gm...> wrote:
> Alright, before I go to bed, I found the following line in
> src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the
> difference:
>
> set_clipbox(gc.cliprect, rendererBase);
>
> Commenting out this line fixes my problem. I'm not sure why it's a
> problem, (maybe a missing restore to previous state somewhere?). I'll
> look into this tomorrow, but it would probably be a lot easier with
> someone familiar with the code.

Following up again, it seems like the problem is that draw_marker is
calling set_clipbox() on the rendererBase instead of theRasterizer,
which is done at 7 other places in the code (as opposed to only one
other location for rendererBase).  Since rendererBase is used for
restore_region, this makes sense as to why it would fix my problem. I
can confirm making the change fixes my problem and doesn't cause any
other issues in my (admittedly brief so far) testing.

(If this isn't the proper fix, an alternative is to call
rendererBase.reset_clipping(true), but I really think this is working
around the issue).

Can someone more familiar with the agg backend weigh in here? I'm
pretty comfortable with the fix, but don't want to be responsible for
breaking pretty much all of matplotlib.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Do we want to add a note to the CHANGELOG for this?

Ben Root

On Wed, Jun 30, 2010 at 4:43 PM, Eric Firing <ef...@ha...> wrote:

> On Wed, 2010-06-30 at 23:08 +0200, Peter Butterworth wrote:
> > On Wed, Jun 30, 2010 at 3:42 AM, Eric Firing <ef...@ha...> wrote:
> > > On Tue, 2010-06-29 at 16:01 -0700, butterw wrote:
> > >> My understanding is that the proposed change will break at least some
> > >> existing code, hence my proposal to go the safer route.
> > >
> > > On what is that understanding based?  Any actual examples or use cases?
> > >
> > > I think the only such cases would be interactive scripts.  One can
> > > imagine a script in which a plot is made, the user views it, perhaps
> > > uses a gui to change the limits, then presses a button to plot the next
> > > data set on top of the first, expecting that it will again autoscale,
> > > and so forth.  Maybe this is sufficient justification for leaving the
> > > present version alone.  That is what I am trying to find out.  In
> > > addition, the change would require scanning the internal mpl code to
> see
> > > whether there are uses of set_xlim that would have to be changed.
> >
> > The points you make are exactly what I was thinking about.
> > A subtle alteration of the behaviour of matplotlib caused by the
> > change is the worse case scenario, because it might not be
> > straightforward to detect/correct.
> > I also have a number of matplotlib interactive scripts /GUIs used in
> > production. Most rely on precise control of the viewing area and some
> > will be affected by the change.
> >
> > >
> > >>
> > >> Also I'm unconvinced by the justification for the change :
> > >> xlim and autoscalex_on are independant attributes, why then should
> setting
> > >
> > > They are not independent, they are potentially in conflict--two
> > > mechanisms fighting for control of the axis.
> > >
> > >> xlim have the side effect of turning autoscalex off ? This is not
> consistent
> > >> with how the API works. If I really wanted autoscalex off, I would
> have
> > >> specified it.
> > >
> > > The idea of having interactive plotting commands is to make the
> > > interaction easy and natural.  When you call set_xlim interactively, it
> > > is because that is what you want the limits to be.  At least that point
> > > of view has been expressed several times on the lists.  I have yet to
> > > hear someone say, "I rely on the present behavior".  In scripts, when
> > > there is no interactive scenario such as I described in the previous
> > > paragraph, the problem with the present behavior is that it means
> > > set_xlim has no effect at all if followed by a plot command unless one
> > > has disabled autoscaling either via a kwarg in the plot command, or via
> > > ax.set_autoscalex_on(False).  The latter is just plain ugly, to my eye.
> >
> > My personal opinion is that the current behaviour is not broken.
> > When typing commands interactively in pylab or writing a regular
> > script it can be frustrating. But in interactive GUIs it is useful to
> > have full independent control over the two parameters.
> > In most cases I agree that the proposed behaviour is what the user
> > wants. But this is not true in all cases.
> >
> > >> To sum things up:
> > >> Adding an argument to set_xlim to allow autoscale to be turned off in
> the
> > >> same step would be a good idea. But it shouldn't suddenly become the
> default
> > >> behaviour.
> > >
> > > You may well be right about this.  In any case, I suspect no change
> will
> > > occur prior to the 1.0 release.
> > >
> > > Additional perspective: the behavior of Matlab's xlim is as I have
> > > proposed, not as mpl xlim presently works.  I don't believe in
> following
> > > Matlab slavishly--sometimes we can make better choices than Matlab
> > > has--but I think that this is a case where Matlab got it right and we
> > > did not, the first time around.  This may be because the _autoscalex
> and
> > > _autoscaley attributes were added to the mpl Axes long after set_xlim.
> >
> > As the change of default behaviour seems to be going ahead, I must
> > request the addition of an new argument to xlim (autoscalex=False).
> > The purpose being to allow the user to modify his code to retain the
> > current behaviour when desired.
>
> I made two commits, 8479 and 8480.  Other developers are welcome to
> revert them or modify them as needed.  Certainly they need testing and
> review, the more, the better.  I had to change quite a few things, so
> there is risk, as you note.  I am a bit concerned about whether enough
> people will be able to do enough testing of this before release to shake
> out any bugs.
>
> The new kwarg for set_xlim and set_ylim is simply "auto"; set it to None
> to obtain the old behavior:
>
>          *auto*: [ True | False | None ]
>            turn *x* autoscaling on (True), off (False; default),
>            or leave unchanged (None)
>
> set_xbound retains the old behavior, by calling set_xlim with auto=None.
>
> We have several options at present.  If the changes I made are junk,
> they can be discarded, or deferred until more time is available for
> testing and reworking.  If they are basically sound but too abrupt, then
> the default could be changed to auto=None, with the possibility of
> shifting it later.  Additionally, an rcparam could be used, although I
> don't like making ever more rcparams.
>
> In addition to the changes to set_xlim, I tried to clarify the
> documentation, and I added an "autoscale" convenience method and pyplot
> function, which I think was needed.
>
> One more change I would like to see is the simple and, I think, safe one
> of supporting descriptive kwarg names alongside the present misleading
> ones: e.g. for xlim, "left" would be equivalent to "xmin", etc.
>
>
> I am on a ship until July 5, working with a high-latency internet
> connection through an intermediate machine, and I can't afford much more
> time on this while I am out here. (And working with svn from here is
> pretty cumbersome.)
>
> Eric
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hello all,

I have always been a bit troubled with how Axes3D object is a bit of a
2nd-class citizen in matplotlib.  In particular, it is very common to create
a new axes using .add_subplot() or .gca(), but you can't do that with
Axes3D.  You also can't create subplots of 3d figures, you have to create
multiple figures with single 3d plots in them.

My examination off the code have not revealed anything that prevents this
from happening.  Currently, the gca() and add_subplot() functions accept a
kwarg of 'projection' which allows one to specify the name of a registered
axes object.  Currently axes.Axes, polar and a few others are registered,
with axes.Axes being default.

I have found that 3 lines of code in the axes3d module to have it add the
Axes3D class to the registry.  Using a name of '3d', one can specify the
projection to gain a Axes3d object.  Note, you will still have to import the
Axes3D object as usual.  Attached is a patch for axes3d.py and a file that
could be added to mpl_examples/.  Give it a shot and let me know how it
works for you!

Enjoy!
Ben Root

P.S. - Can you just imagine subplots of animated 3d plots? wink... wink...

Alright, before I go to bed, I found the following line in
src/_backend_agg.cpp at line 709 (in draw_markers()) makes all the
difference:

set_clipbox(gc.cliprect, rendererBase);

Commenting out this line fixes my problem. I'm not sure why it's a
problem, (maybe a missing restore to previous state somewhere?). I'll
look into this tomorrow, but it would probably be a lot easier with
someone familiar with the code.

Ryan

On Sat, Jul 3, 2010 at 12:33 AM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> I've been debugging this for hours now and could really use the help
> of someone smarter than me. In working on blitting with animations,
> I've run into a problem when trying to use blitting + multiple
> subplots + lines with markers. It's an esoteric combination to be
> sure, but I have a script (attached) that demonstrates my problem.  As
> far as I can tell, the addition of a marker to a line object causes to
> canvas.restore_region() to no longer function (I've paused the
> animation, after a blit to flush the draw, after every stage). The
> data in the region saved from copy_from_bbox is fine, but calling
> restore_region() with it has no effect.  Removing marker from the line
> specification causes the problem to disappear.  The net effect of the
> problem is that the other subplot (than the one with the marker) does
> not have the previous draw cleared, resulting in a smearing effect.
>
> Anybody have a clue?
>
> Ryan
>
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma
>



-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,

I've been debugging this for hours now and could really use the help
of someone smarter than me. In working on blitting with animations,
I've run into a problem when trying to use blitting + multiple
subplots + lines with markers. It's an esoteric combination to be
sure, but I have a script (attached) that demonstrates my problem.  As
far as I can tell, the addition of a marker to a line object causes to
canvas.restore_region() to no longer function (I've paused the
animation, after a blit to flush the draw, after every stage). The
data in the region saved from copy_from_bbox is fine, but calling
restore_region() with it has no effect.  Removing marker from the line
specification causes the problem to disappear.  The net effect of the
problem is that the other subplot (than the one with the marker) does
not have the previous draw cleared, resulting in a smearing effect.

Anybody have a clue?

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma