On Tue, Jul 10, 2012 at 05:36:50PM -0400, Tony Yu wrote: > On Tue, Jul 10, 2012 at 1:52 PM, John Hunter <jd...@gm...> wrote: > > > > > On Tue, Jul 10, 2012 at 12:49 PM, Damon McDougall < > > dam...@gm...> 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). 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). -- 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 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
On Wed, Jul 11, 2012 at 10:23:32AM -0500, John Hunter 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 +1 on the helper function. That's probably a much less bloated of way of doing it. -- 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 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 > 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:27 AM, 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 >> > > 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 > > 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: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). Cheers! Ben Root
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 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 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 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 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 3:33 PM, 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`). > > > > 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
On Jul 13, 2012, at 7:57 AM, Benjamin Root <ben...@ou...> wrote: > 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 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 > 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 -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom
On Fri, Jul 13, 2012 at 7:01 PM, 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 > > > > 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? > Your suggestion would be consistent with how errorbar() works, I think. Ben Root
On Wed, Jul 11, 2012 at 5:23 PM, 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 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 Tue, Jul 17, 2012 at 6:25 AM, todd rme <tod...@gm...> wrote: > On Wed, Jul 11, 2012 at 5:23 PM, 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 > > 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 > Intriguing idea. I am actually quite comfortable with that. Ben Root
On Tue, Jul 17, 2012 at 08:21:50AM -0500, Benjamin Root wrote: > On Tue, Jul 17, 2012 at 6:25 AM, todd rme <tod...@gm...> wrote: > > > On Wed, Jul 11, 2012 at 5:23 PM, 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 > > > > 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 > > > > Intriguing idea. I am actually quite comfortable with that. > I like this idea, too. > Ben Root -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom