On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall <damon.mcdougall@gmail.com> 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@ou.edu> wrote:
>
> >
> >
> > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@gmail.com> wrote:
> >
> >>
> >>
> >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> >> damon.mcdougall@gmail.com> 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