On Thu, Jul 12, 2012 at 3:33 PM, 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`).
>

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