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).
···
On Tue, Jul 10, 2012 at 05:36:50PM -0400, Tony Yu wrote:
On Tue, Jul 10, 2012 at 1:52 PM, John Hunter <jdh2358@...149...> wrote:
>
> On Tue, Jul 10, 2012 at 12:49 PM, Damon McDougall < > > damon.mcdougall@...149...> wrote:
>
>>
>> Would there be any interest in porting some of that functionality into
>> the main mpl codebase? Like Ben said, that error function is nifty... 
>>
>>
>
> I also think the styles would be widely appreciated, and we might get more
> styles contributors if it was part of the mainline. We'd ideally like to
> be able to support remote styles, eg via gist.
>
> Nice stuff, Tony.
>
>
Damon and John: Thanks for your interest. I would be happy to help port
anything that can find a home in Matplotlib. I'm low on bandwidth, so if
I'm too slow with any of it, feel free to grab the code and submit your own
PR for the port (just let me know so we don't duplicate our efforts).
--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
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
···
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…149…> 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).
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
···
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…149…> 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
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
···
On Wed, Jul 11, 2012 at 11:27 AM, Benjamin Root <ben.root@…553…> wrote:
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…149…> 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
+1 on the helper function. That's probably a much less bloated of way of
doing it.
···
On Wed, Jul 11, 2012 at 10:23:32AM -0500, John Hunter wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@...149... > > 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
--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
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
···
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…149…> 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
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
···
On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@…553…> wrote:
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…149…> wrote:
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?
···
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.root@...553...> wrote:
>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...149...> wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdougall@...149...> 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
>
>
--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
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
···
On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall <damon.mcdougall@…149…> 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.root@…553…> wrote:
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@…149…> 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
Aha, the answer was 'yes, I was missing something'!
Thanks.
···
On Thu, Jul 12, 2012 at 09:41:32AM -0400, Tony Yu wrote:
On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall > <damon.mcdougall@...149...>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.root@...553...> wrote:
> >
> > >
> > >
> > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...149...> > > wrote:
> > >
> > >>
> > >>
> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@...149...> 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
--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
>
>
>
>>
>>
>>>
>>> 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?
···
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.root@...553...> wrote:
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...149...> wrote:
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdougall@...149...> wrote:
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
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
···
On Thu, Jul 12, 2012 at 3:33 PM, Damon McDougall <damon.mcdougall@…149…> 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.root@…553…> wrote:
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@…149…> 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?
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 Jul 13, 2012, at 7:57 AM, Benjamin Root <ben.root@…553…> 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
···
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.root@...553...> wrote:
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...149...> wrote:
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdougall@...149...> wrote:
--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
Your suggestion would be consistent with how errorbar() works, I think.
Ben Root
···
On Fri, Jul 13, 2012 at 7:01 PM, Damon McDougall <damon.mcdougall@…149…> 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.root@…553…> wrote:
On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@…149…> 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?
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
···
On Wed, Jul 11, 2012 at 5:23 PM, John Hunter <jdh2358@...149...> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall > <damon.mcdougall@...149...> 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
Intriguing idea. I am actually quite comfortable with that.
Ben Root
···
On Tue, Jul 17, 2012 at 6:25 AM, todd rme <toddrme2178@…149…> wrote:
On Wed, Jul 11, 2012 at 5:23 PM, John Hunter <jdh2358@…149…> wrote:
On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall > > > <damon.mcdougall@…322…9…> 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