matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] mpl BOFs

[Benjamin R. <ben...@ou...>]

Also, if desired, we could also set a different time.

On Wed, Jul 18, 2012 at 5:11 PM, Benjamin Root <ben...@ou...> wrote:

> technically, there is supposed to be a BOF about now, but I just realized
> that no location was specified.  We could meet in the atrium unless anyone
> has a better idea.
>
> Ben
>

[matplotlib-devel] mpl BOFs

[Benjamin R. <ben...@ou...>]

technically, there is supposed to be a BOF about now, but I just realized
that no location was specified.  We could meet in the atrium unless anyone
has a better idea.

Ben

Re: [matplotlib-devel] Interrupt is fixed

[Phil E. <pel...@gm...>]

Ben, actually the PyQt4 backend is responsible for this (a hello world
pyqt4 application doesn't accept sigint). However, I have fixed master
(in the aforementioned PR) so that ctrl+c from the command line
actually closes the figure.

HTH,

On 18 July 2012 20:00, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Jul 18, 2012 at 1:40 PM, Neal Becker <ndb...@gm...> wrote:
>>
>> OK, my mistake.  I'm using 1.1.1rc2.
>>
>> I was using a new installation without any matplotlibrc, and was defaulted
>> to
>> gtk.
>>
>> If I set:
>> backend : Qt4Agg
>>
>> then the problem has returned.
>>
>
> Usually, the source of such problems is someone using a bare try...except.
> KeyboardInterrupt subclasses BaseException.  There is a subtle difference
> between
>
> try:
>    foo()
> except:
>    pass
>
> and
>
> try:
>     foo()
> except Exception:
>     pass
>
> The first will capture Ctrl-C and throw it away, while the latter will not.
> PEP8 recommends against blind usage of bare except clauses.
>
> Happy hunting!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Interrupt is fixed

[Neal B. <ndb...@gm...>]

I'm afraid it's only an annoyance, and I doubt I'll be motivate to try to hunt 
that down.

Benjamin Root wrote:

> On Wed, Jul 18, 2012 at 1:40 PM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> OK, my mistake.  I'm using 1.1.1rc2.
>>
>> I was using a new installation without any matplotlibrc, and was defaulted
>> to
>> gtk.
>>
>> If I set:
>> backend : Qt4Agg
>>
>> then the problem has returned.
>>
>>
> Usually, the source of such problems is someone using a bare try...except.
> KeyboardInterrupt subclasses BaseException.  There is a subtle difference
> between
> 
> try:
>    foo()
> except:
>    pass
> 
> and
> 
> try:
>     foo()
> except Exception:
>     pass
> 
> The first will capture Ctrl-C and throw it away, while the latter will
> not.  PEP8 recommends against blind usage of bare except clauses.
> 
> Happy hunting!
> Ben Root

Re: [matplotlib-devel] Interrupt is fixed

[Benjamin R. <ben...@ou...>]

On Wed, Jul 18, 2012 at 1:40 PM, Neal Becker <ndb...@gm...> wrote:

> OK, my mistake.  I'm using 1.1.1rc2.
>
> I was using a new installation without any matplotlibrc, and was defaulted
> to
> gtk.
>
> If I set:
> backend : Qt4Agg
>
> then the problem has returned.
>
>
Usually, the source of such problems is someone using a bare try...except.
KeyboardInterrupt subclasses BaseException.  There is a subtle difference
between

try:
   foo()
except:
   pass

and

try:
    foo()
except Exception:
    pass

The first will capture Ctrl-C and throw it away, while the latter will
not.  PEP8 recommends against blind usage of bare except clauses.

Happy hunting!
Ben Root

Re: [matplotlib-devel] Interrupt is fixed

[Neal B. <ndb...@gm...>]

OK, my mistake.  I'm using 1.1.1rc2.

I was using a new installation without any matplotlibrc, and was defaulted to 
gtk.

If I set:
backend : Qt4Agg

then the problem has returned.


Phil Elson wrote:

> Presumably you mean on the qt4 backend? If so, glad to be of some help! :-)
> 
> The change came in in PR #851
> (https://github.com/matplotlib/matplotlib/pull/851/files#diff-7) and
> also allows you to close a figure with ctrl+w and make a qt4 figure
> fullscreen with "ctrl+f" (actually, just "f" will do, but I have an
> ambition to nuke the non-controled versions by default).
> 
> 
> UPDATE: I've just noticed that your traceback is showing your backend
> as gtk, for which I cannot take any credit (nor do I know the change
> which caused this improvement).
> 
> 
> 
> On 18 July 2012 13:06, Neal Becker
> <ndb...@gm...> wrote:
>> One annoyance with mpl in the past is that when running a script, SIGINT
>> would not kill it (needed to use C-c C-\ instead).
>>
>> It seems this is now fixed:
>>
>> Interrupt now gives me:
>>
>>   File "/home/nbecker/.local/lib/python2.7/site-
>> packages/matplotlib/backends/backend_gtk.py", line 77, in mainloop
>>     gtk.main()
>> KeyboardInterrupt
>>
>>
>> 
------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: [matplotlib-devel] Interrupt is fixed

[Phil E. <pel...@gm...>]

Presumably you mean on the qt4 backend? If so, glad to be of some help! :-)

The change came in in PR #851
(https://github.com/matplotlib/matplotlib/pull/851/files#diff-7) and
also allows you to close a figure with ctrl+w and make a qt4 figure
fullscreen with "ctrl+f" (actually, just "f" will do, but I have an
ambition to nuke the non-controled versions by default).


UPDATE: I've just noticed that your traceback is showing your backend
as gtk, for which I cannot take any credit (nor do I know the change
which caused this improvement).



On 18 July 2012 13:06, Neal Becker <ndb...@gm...> wrote:
> One annoyance with mpl in the past is that when running a script, SIGINT would
> not kill it (needed to use C-c C-\ instead).
>
> It seems this is now fixed:
>
> Interrupt now gives me:
>
>   File "/home/nbecker/.local/lib/python2.7/site-
> packages/matplotlib/backends/backend_gtk.py", line 77, in mainloop
>     gtk.main()
> KeyboardInterrupt
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Interrupt is fixed

[Neal B. <ndb...@gm...>]

One annoyance with mpl in the past is that when running a script, SIGINT would 
not kill it (needed to use C-c C-\ instead).

It seems this is now fixed:

Interrupt now gives me:

  File "/home/nbecker/.local/lib/python2.7/site-
packages/matplotlib/backends/backend_gtk.py", line 77, in mainloop
    gtk.main()
KeyboardInterrupt

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Damon M. <dam...@gm...>]

On Tue, Jul 17, 2012 at 08:21:50AM -0500, Benjamin Root wrote:
> On Tue, Jul 17, 2012 at 6:25 AM, todd rme <tod...@gm...> wrote:
> 
> > On Wed, Jul 11, 2012 at 5:23 PM, 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
> >
> > What about adding a property to the existing errorbar to let someone
> > change it to the filled version?  This could also, potentially, be
> > extended with other types of error bars if the need arises.
> >
> > -Todd
> >
> 
> Intriguing idea.  I am actually quite comfortable with that.
> 

I like this idea, too.

> Ben Root

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Benjamin R. <ben...@ou...>]

On Tue, Jul 17, 2012 at 6:25 AM, todd rme <tod...@gm...> wrote:

> On Wed, Jul 11, 2012 at 5:23 PM, 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
>
> What about adding a property to the existing errorbar to let someone
> change it to the filled version?  This could also, potentially, be
> extended with other types of error bars if the need arises.
>
> -Todd
>

Intriguing idea.  I am actually quite comfortable with that.

Ben Root

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[todd r. <tod...@gm...>]

On Wed, Jul 11, 2012 at 5:23 PM, 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

What about adding a property to the existing errorbar to let someone
change it to the filled version?  This could also, potentially, be
extended with other types of error bars if the need arises.

-Todd

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Benjamin R. <ben...@ou...>]

On Fri, Jul 13, 2012 at 7:01 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
> >
>
> 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?
>

Your suggestion would be consistent with how errorbar() works, I think.

Ben Root

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Damon M. <dam...@gm...>]

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

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[John H. <jd...@gm...>]

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. 

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Benjamin R. <ben...@ou...>]

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

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Damon M. <dam...@gm...>]

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?

> Cheers,
> -Tony
> 
> 
> > Cheers!
> > Ben Root
> >
> >

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Damon M. <dam...@gm...>]

On Thu, Jul 12, 2012 at 09:41:32AM -0400, Tony Yu wrote:
> On Thu, Jul 12, 2012 at 9:28 AM, 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`).
> > >
> > > Cheers,
> > > -Tony
> > >
> > >
> > > > Cheers!
> > > > Ben Root
> > > >
> > > >
> >
> > Woohoo! Something other than my thesis to do! I have one question. It
> > looks like your function `extrema_from_error_input` just adds +/- an
> > error scalar (or array), but in the gallery it looks like the padding
> > is thinner in the areas of the `sin` function where the magnitude of the
> > gradient is larger. Is this the case, or am I missing something?
> >
> > --
> > Damon McDougall
> >
> 
> 
> Yep, that's the way it should look because it's adding the error just in
> the y-direction. To get a constant thickness, you'd have to add a constant
> orthogonal to the line's slope.
> 
> Good luck procrastinating on your thesis ;)
> -Tony

Aha, the answer was 'yes, I was missing something'! :)
Thanks.

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Tony Yu <ts...@gm...>]

On Thu, Jul 12, 2012 at 9:28 AM, 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`).
> >
> > Cheers,
> > -Tony
> >
> >
> > > Cheers!
> > > Ben Root
> > >
> > >
>
> Woohoo! Something other than my thesis to do! I have one question. It
> looks like your function `extrema_from_error_input` just adds +/- an
> error scalar (or array), but in the gallery it looks like the padding
> is thinner in the areas of the `sin` function where the magnitude of the
> gradient is larger. Is this the case, or am I missing something?
>
> --
> Damon McDougall
>


Yep, that's the way it should look because it's adding the error just in
the y-direction. To get a constant thickness, you'd have to add a constant
orthogonal to the line's slope.

Good luck procrastinating on your thesis ;)
-Tony

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Damon M. <dam...@gm...>]

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`).
> 
> Cheers,
> -Tony
> 
> 
> > Cheers!
> > Ben Root
> >
> >

Woohoo! Something other than my thesis to do! I have one question. It
looks like your function `extrema_from_error_input` just adds +/- an
error scalar (or array), but in the gallery it looks like the padding
is thinner in the areas of the `sin` function where the magnitude of the
gradient is larger. Is this the case, or am I missing something?

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Tony Yu <ts...@gm...>]

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`).

Cheers,
-Tony


> Cheers!
> Ben Root
>
>

Re: [matplotlib-devel] Hacking on matplotlib

[Paul I. <piv...@gm...>]

On Tue, Jul 10, 2012 at 8:06 PM, Benjamin Root <ben...@ou...> wrote:
> On Tuesday, July 10, 2012, Mike Kaufman wrote:
>>
>> It would be nice to have the label and title methods take a Text object
>> (and a list of text objects -- each of whom could supply a piece of
>> different colored text) in addition to a string.
>>
>> A list of text objects would be automagically concatenated together. How
>> to generalize alignment of multiple text objects? Haven't thought that
>> far yet.
>>
>> Either that or develop some additional color markup (and a parser)
>> inside a string. Admittedly a bigger project -- though probably a better
>> solution.
>>
>> M
>>
>
> That is already a wishlist item.  Feel free to comment on its discussion
> thread with your ideas.

For reference, I believe Ben's referring to #697 [1], for which I provided a
possible implementation, which has the automagic concatenation you seek.

1. https://github.com/matplotlib/matplotlib/issues/697

best,

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Benjamin R. <ben...@ou...>]

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

Cheers!
Ben Root

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Damon M. <dam...@gm...>]

On Wed, Jul 11, 2012 at 10:23:32AM -0500, John Hunter 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

+1 on the helper function. That's probably a much less bloated of way of
doing it.

-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Tony Yu <ts...@gm...>]

On Wed, Jul 11, 2012 at 11:27 AM, 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
>>
>
> At the very least, it should be added to the gallery.  Also, one thing
> that might (or might not) get in the way of getting merged into mainline
> mpl is how well it interacts with legends.  What does it produce in the
> legend?
>
> Ben Root
>
>
As I said before, it is a really simple function: I wrote `errorfill` just
to get an interface that is somewhat similar to `errorbar`. I tend to think
that the Axes object is a bit bloated, so I'm inclined to agree that it
might be best leave it out of matplotlib-proper. +1 on the gallery, though.

Ben: Good point about the legend-interaction. I just added a fix on github;
here's the result:


http://tonysyu.github.com/mpltools/auto_examples/special/plot_errorfill.html

Cheers,
-Tony

Re: [matplotlib-devel] [Matplotlib-users] ANN: mpltools 0.1 release

[Benjamin R. <ben...@ou...>]

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
>

At the very least, it should be added to the gallery.  Also, one thing that
might (or might not) get in the way of getting merged into mainline mpl is
how well it interacts with legends.  What does it produce in the legend?

Ben Root