matplotlib-devel Mailing List for matplotlib

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

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

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

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

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

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