matplotlib-users Mailing List for matplotlib

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
> 
> >
> >
> > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
> >
> >>
> >>
> >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> >> dam...@gm...> wrote:
> >>>
> >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> >>> complicated, either. I'd be more than happy to port it over later today
> >>> when I get bored of typing up my thesis. It'll probably only take me
> >>> about 30 minutes.
> >>>
> >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> >>> evening (British Summer (hah!) Time).
> >>>
> >>
> >>
> >> While it is a nice graph, I am not sure that the use case is common
> >> enough to justify a new plotting method. One can get the same result with:
> >>
> >>
> >> In [68]: x = np.linspace(0, 2 * np.pi)
> >>
> >> In [69]: y_sin = np.sin(x)
> >>
> >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> >>
> >> In [71]: plot(x, y_sin)
> >> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> >>
> >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> >> facecolor='red', alpha=0.5)
> >> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> >>
> >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> >> adding a new plotting method, perhaps we would be better off with a helper
> >> method to create the xs and ys for fill_between
> >>
> >> xs, ys = mlab.pad_line(x, y, 0.2)
> >> fill_between(xs, ys)
> >>
> >> JDH
> >>
> >
> >
> > I could definitely agree with a pad_line() function. We might want to
> > revisit the issue of how much visibility the mlab module should get in the
> > documentation (it currently doesn't get much at all). My whole take on
> > mlab was that it was a left-over from the days of working around issues in
> > NumPy and SciPy and that it was being slowly phased out. As for other
> > possible locations, cbook feels like it is more for the devs than for the
> > users, and adding it to pyplot would render the whole purpose of creating
> > this function as opposed to errorfill moot.
> >
> > As an additional point about such a pad_line function, it should probably
> > be nice to mirror the errorbar() functionality to allow not only a constant
> > error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar()
> > for the 2xN array case does -row1 and +row2).
> >
> 
> Damon: it sounds like you're volunteering to submit a PR to add this
> function ;)
> 
> Here's the relevant bit (which should already handle the cases Ben mentions
> above):
> 
> 
> https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> 
Great. I've basically done this. I have one suggestion, though. In the
case where len(zerr) == 2, you are setting
zmin, zmax = zerr
I think it makes more sense to set
zmin, zmax = z - zerr[0], z + zerr[1]
What do you think?
> It needs a docstring and a home (pyplot.py?). I kind of think `offset_line`
> is more explicit than `pad_line` (both of these are *much* better than my
> original `extrema_from_error_input`).
> 
> Cheers,
> -Tony
> 
> 
> > Cheers!
> > Ben Root
> >
> >
Best,
Damon
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

The UTM support is great. Thanks for that. 
Is there a possibility to display the projected coordinates without the
reduction of the x/y coordinates to 0/0 in the left bottom corner?
Regards,
 Stefan.

On Jul 13, 2012, at 7:57 AM, Benjamin Root <ben...@ou...> wrote:
> There was talk of this living in mlab or cbook. Is there a preference?
> 
> 
> Neither. cbook is really meant more for the devs. Half of it is converter functions that are probably completely unneeded now, while the other half is the callback registry. 
I disagree that cbook is meant for devs. I initially used cbook as a place to put neat recipes from the python cookbook. It has grown a bit from there. The stuff that is in there like "is_string_like" is generically useful. 
The converters are used by the rec2* funcs, eg the rec2excel function in the exceltools toolkit. I use these extensively. 
> Luckily, the module is called "cbook.py", so one could pretend that it isn't "cookbook" but rather "callback book"...
> 
> Meanwhile, mlab's own documentation says: "Numerical python functions written for compatability with MATLAB
> commands with the same names." So, unless someone can find out if MATLAB has some sort of equivalent functionality hidden away somewhere, it doesn't belong there either.
> 
Or better, we change the docstring. I think of mlab as a place to put numerical or semi-numerical stuff in support of plotting. 
> Not sure where to put it.
mlab is probably the best place. 

On Thu, Jul 12, 2012 at 3:33 PM, Damon McDougall
<dam...@gm...>wrote:
> On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben...@ou...> wrote:
> >
> > >
> > >
> > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...>
> wrote:
> > >
> > >>
> > >>
> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> > >> dam...@gm...> wrote:
> > >>>
> > >>> Well, as Ben said, that error fill plot is neato! It doesn't look too
> > >>> complicated, either. I'd be more than happy to port it over later
> today
> > >>> when I get bored of typing up my thesis. It'll probably only take me
> > >>> about 30 minutes.
> > >>>
> > >>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> > >>> evening (British Summer (hah!) Time).
> > >>>
> > >>
> > >>
> > >> While it is a nice graph, I am not sure that the use case is common
> > >> enough to justify a new plotting method. One can get the same result
> with:
> > >>
> > >>
> > >> In [68]: x = np.linspace(0, 2 * np.pi)
> > >>
> > >> In [69]: y_sin = np.sin(x)
> > >>
> > >> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> > >>
> > >> In [71]: plot(x, y_sin)
> > >> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> > >>
> > >> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> > >> facecolor='red', alpha=0.5)
> > >> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> > >>
> > >> Admittedly the [::-1] thing is a bit counter-intuitive, but rather
> than
> > >> adding a new plotting method, perhaps we would be better off with a
> helper
> > >> method to create the xs and ys for fill_between
> > >>
> > >> xs, ys = mlab.pad_line(x, y, 0.2)
> > >> fill_between(xs, ys)
> > >>
> > >> JDH
> > >>
> > >
> > >
> > > I could definitely agree with a pad_line() function. We might want to
> > > revisit the issue of how much visibility the mlab module should get in
> the
> > > documentation (it currently doesn't get much at all). My whole take on
> > > mlab was that it was a left-over from the days of working around
> issues in
> > > NumPy and SciPy and that it was being slowly phased out. As for other
> > > possible locations, cbook feels like it is more for the devs than for
> the
> > > users, and adding it to pyplot would render the whole purpose of
> creating
> > > this function as opposed to errorfill moot.
> > >
> > > As an additional point about such a pad_line function, it should
> probably
> > > be nice to mirror the errorbar() functionality to allow not only a
> constant
> > > error, but also a N, Nx1, or 2xN array of +/- error. (note that
> errorbar()
> > > for the 2xN array case does -row1 and +row2).
> > >
> >
> > Damon: it sounds like you're volunteering to submit a PR to add this
> > function ;)
> >
> > Here's the relevant bit (which should already handle the cases Ben
> mentions
> > above):
> >
> >
> >
> https://github.com/tonysyu/mpltools/blob/master/mpltools/special/errorfill.py#L54
> >
> > It needs a docstring and a home (pyplot.py?). I kind of think
> `offset_line`
> > is more explicit than `pad_line` (both of these are *much* better than my
> > original `extrema_from_error_input`).
> >
>
> There was talk of this living in mlab or cbook. Is there a preference?
>
>
Neither. cbook is really meant more for the devs. Half of it is converter
functions that are probably completely unneeded now, while the other half
is the callback registry. Luckily, the module is called "cbook.py", so one
could pretend that it isn't "cookbook" but rather "callback book"...
Meanwhile, mlab's own documentation says: "Numerical python functions
written for compatability with MATLAB
commands with the same names." So, unless someone can find out if MATLAB
has some sort of equivalent functionality hidden away somewhere, it doesn't
belong there either.
Not sure where to put it.
Cheers!
Ben Root

Hi Keith,
How are you storing the plot in the frame/panel?
Josh
On Jul 12, 2012, at 11:59 PM, Keith Jones wrote:
> Hi Josh,
> Yes I too am using the wx backend.
> 
> Regards,
> Keith
> 
> From: Tony Yu [mailto:ts...@gm...] 
> Sent: Friday, 13 July 2012 3:16 p.m.
> To: Keith Jones
> Cc: Joshua Koehler; mat...@li...
> Subject: Re: [Matplotlib-users] wxpython matplotlib figure resize
> 
> 
> On Thu, Jul 12, 2012 at 9:27 PM, Keith Jones <K....@ir...> wrote:
> Hi,
> I am interested in a better solution to this problem, but I have used this simple method to force the right size.
> 
> def tickle(self):
> #gets frame to redraw and resize, not elegant.
> if self.IsMaximized(): #then needs a kick
> self.Restore()
> self.Maximize()
> else:
> x,y = self.GetSize()
> self.SetSize((x-1, y-1))
> self.SetSize((x, y))
> 
> Regards,
> Keith
> 
> From: Joshua Koehler [mailto:jjk...@gm...] 
> Sent: Saturday, 7 July 2012 1:51 a.m.
> To: mat...@li...
> Subject: [Matplotlib-users] wxpython matplotlib figure resize
> 
> Hi all,
> 
> I am currently trying to use matplotlib with wxPython and all is going well except for one annoying issue that I can't figure out. 
> 
> I initialize a wxcanvas object with a figure and then throughout the life of the program I want the canvas' figure to change and display the corresponding plot. I can get the change of figure, but when the program goes to plot, the figure isn't the right size. It changes to the right size only when I manually resize the figure (see attached images). Is there some command that I am missing? This is the update sequence I am using:
> 
> self.figure = figure
> 
> self.canvas.figure.clear()
> self.canvas.figure = self.figure
> self.canvas.draw()
> self.color_background()
> 
> #self.GetParent().Layout()
> #self.SetSizer(self.main_sizer)
> #self.Fit()
> self.SendSizeEvent()
> 
> As you can tell from the comments (there are more in my code), I have tried a variety of ways to update the figure off the bat.
> 
> Thanks!
> 
> Josh
> 
> 
> This may be similar to a Qt-backend bug, which didn't take the toolbar into account when resizing the figure:
> https://github.com/matplotlib/matplotlib/pull/756
> It doesn't quite fit, though, because Josh's original example shows a figure that's the correct size (but the axes doesn't fill the figure). The toolbar issue tended to squish the axes in the vertical direction (at least in the GUI window), whereas Josh's example is squished in the horizontal direction.
> 
> Keith: Are you also using the Wx-backend? I don't have Wx installed so I can't provide much help. I've been planning to take a look at a similar issue in the Tk backend, but haven't had time.
> 
> Best,
> -Tony
> 
> 
> 
> 
> This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.

Thanks for the explanation! Let's discuss further on that issue page.
Michiel de Hoon <mjl...@ya...> writes:
> Hi Eric, Jouni,
>
> Thanks for your replies. I opened an issue here:
>
> https://github.com/matplotlib/matplotlib/issues/992
>
> and wrote an outline of how the PDF backend can be simplified by
> making use of gc.restore to keep track of the graphics context. In
> essence the PDF backend would then follow the same logic as the Cairo
> and Mac OS X backends, so it may be good to compare to these
> (especially the Cairo backend, since it's written in pure Python and
> easy to understand).
>
> Best,
> -Michiel.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Hi Josh,
Yes I too am using the wx backend.
Regards,
Keith
________________________________
From: Tony Yu [mailto:ts...@gm...]
Sent: Friday, 13 July 2012 3:16 p.m.
To: Keith Jones
Cc: Joshua Koehler; mat...@li...
Subject: Re: [Matplotlib-users] wxpython matplotlib figure resize
On Thu, Jul 12, 2012 at 9:27 PM, Keith Jones <K....@ir...<mailto:K....@ir...>> wrote:
Hi,
I am interested in a better solution to this problem, but I have used this simple method to force the right size.
 def tickle(self):
 #gets frame to redraw and resize, not elegant.
 if self.IsMaximized(): #then needs a kick
 self.Restore()
 self.Maximize()
 else:
 x,y = self.GetSize()
 self.SetSize((x-1, y-1))
 self.SetSize((x, y))
Regards,
Keith
________________________________
From: Joshua Koehler [mailto:jjk...@gm...<mailto:jjk...@gm...>]
Sent: Saturday, 7 July 2012 1:51 a.m.
To: mat...@li...<mailto:mat...@li...>
Subject: [Matplotlib-users] wxpython matplotlib figure resize
Hi all,
I am currently trying to use matplotlib with wxPython and all is going well except for one annoying issue that I can't figure out.
I initialize a wxcanvas object with a figure and then throughout the life of the program I want the canvas' figure to change and display the corresponding plot. I can get the change of figure, but when the program goes to plot, the figure isn't the right size. It changes to the right size only when I manually resize the figure (see attached images). Is there some command that I am missing? This is the update sequence I am using:
self.figure = figure
 self.canvas.figure.clear()
 self.canvas.figure = self.figure
 self.canvas.draw()
 self.color_background()
 #self.GetParent().Layout()
 #self.SetSizer(self.main_sizer)
 #self.Fit()
 self.SendSizeEvent()
As you can tell from the comments (there are more in my code), I have tried a variety of ways to update the figure off the bat.
Thanks!
Josh
This may be similar to a Qt-backend bug, which didn't take the toolbar into account when resizing the figure:
https://github.com/matplotlib/matplotlib/pull/756
It doesn't quite fit, though, because Josh's original example shows a figure that's the correct size (but the axes doesn't fill the figure). The toolbar issue tended to squish the axes in the vertical direction (at least in the GUI window), whereas Josh's example is squished in the horizontal direction.
Keith: Are you also using the Wx-backend? I don't have Wx installed so I can't provide much help. I've been planning to take a look at a similar issue in the Tk backend, but haven't had time.
Best,
-Tony
________________________________
This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.

On Thu, Jul 12, 2012 at 9:27 PM, Keith Jones <K....@ir...> wrote:
> Hi,
>
> I am interested in a better solution to this problem, but I have used this
> simple method to force the right size.
>
>
>
> def tickle(self):
>
> #gets frame to redraw and resize, not elegant.
>
> if self.IsMaximized(): #then needs a kick
>
> self.Restore()
>
> self.Maximize()
>
> else:
>
> x,y = self.GetSize()
>
> self.SetSize((x-1, y-1))
>
> self.SetSize((x, y))
>
>
>
> Regards,
>
> Keith
>
>
> ------------------------------
>
> *From:* Joshua Koehler [mailto:jjk...@gm...]
> *Sent:* Saturday, 7 July 2012 1:51 a.m.
> *To:* mat...@li...
> *Subject:* [Matplotlib-users] wxpython matplotlib figure resize
>
>
>
> Hi all,
>
> I am currently trying to use matplotlib with wxPython and all is going
> well except for one annoying issue that I can't figure out.
>
> I initialize a wxcanvas object with a figure and then throughout the life
> of the program I want the canvas' figure to change and display the
> corresponding plot. I can get the change of figure, but when the program
> goes to plot, the figure isn't the right size. It changes to the right size
> only when I manually resize the figure (see attached images). Is there some
> command that I am missing? This is the update sequence I am using:
>
> self.figure = figure
>
> self.canvas.figure.clear()
> self.canvas.figure = self.figure
> self.canvas.draw()
> self.color_background()
>
> #self.GetParent().Layout()
> #self.SetSizer(self.main_sizer)
> #self.Fit()
> self.SendSizeEvent()
>
> As you can tell from the comments (there are more in my code), I have
> tried a variety of ways to update the figure off the bat.
>
> Thanks!
>
> Josh
>
>
> This may be similar to a Qt-backend bug, which didn't take the toolbar
into account when resizing the figure:
https://github.com/matplotlib/matplotlib/pull/756
It doesn't quite fit, though, because Josh's original example shows a
figure that's the correct size (but the axes doesn't fill the figure). The
toolbar issue tended to squish the axes in the vertical direction (at least
in the GUI window), whereas Josh's example is squished in the horizontal
direction.
Keith: Are you also using the Wx-backend? I don't have Wx installed so I
can't provide much help. I've been planning to take a look at a similar
issue in the Tk backend, but haven't had time.
Best,
-Tony