On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.r...@ou.edu> wrote:
>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2...@gmail.com> wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
>> damon.mcdoug...@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
>
>
------------------------------------------------------------------------------
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-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
