From: Tony Yu <ts...@gm...> - 2012-07-10 16:59:07
|
Announcement: mpltools 0.1 ========================== mpltools is a package of tools for matplotlib. For the most part, these tools are only loosely-connected in functionality, but there are two that may prove particularly useful: Styles and plot2rst ------------------- The `style` package provides a simple way to define and reuse matplotlibrc-like config files. For example, there's an included style that mimics R's plotting package, ggplot. You can use this style by calling:: from mpltools import style style.use('ggplot') (Thanks to Huy Nguyen for these settings.) The second tool of note is `plot2rst`, which provides a simple way to generate (Sphinx-flavored) reStructuredText examples from normal python files. See the Getting Started page and `plot2rst` example for details: http://tonysyu.github.com/mpltools/getting_started.html http://tonysyu.github.com/mpltools/auto_examples/sphinx/plot_plot2rst.html Other tools ----------- This package provides other tools for tweaking colors, layouts, etc. The easiest way to get started is to look at the example gallery: http://tonysyu.github.com/mpltools/auto_examples/index.html Download -------- You can grab the 0.1 release on PyPI: http://pypi.python.org/pypi/mpltools/0.1 or clone the repo on github: https://github.com/tonysyu/mpltools.git Contributors ------------ Thanks the following people for reporting bugs and contributing fixes and enhancements: - Alex Arsenovic - Guillaume Calmettes - Huy Nguyen - Sergey Karayev Special thanks to Alex, who came up with an early implementation of stylesheets that started me down this path. |
From: Benjamin R. <ben...@ou...> - 2012-07-10 17:11:01
|
On Tue, Jul 10, 2012 at 12:58 PM, Tony Yu <ts...@gm...> wrote: > Announcement: mpltools 0.1 > ========================== > > mpltools is a package of tools for matplotlib. For the most part, these > tools are only loosely-connected in functionality, but there are two that > may prove particularly useful: > > Styles and plot2rst > ------------------- > > The `style` package provides a simple way to define and reuse > matplotlibrc-like config files. For example, there's an included style that > mimics R's plotting package, ggplot. You can use this style by calling:: > > from mpltools import style > style.use('ggplot') > > (Thanks to Huy Nguyen for these settings.) > > The second tool of note is `plot2rst`, which provides a simple way to > generate (Sphinx-flavored) reStructuredText examples from normal python > files. See the Getting Started page and `plot2rst` example for details: > > http://tonysyu.github.com/mpltools/getting_started.html > > http://tonysyu.github.com/mpltools/auto_examples/sphinx/plot_plot2rst.html > > > Other tools > ----------- > > This package provides other tools for tweaking colors, layouts, etc. The > easiest way to get started is to look at the example gallery: > > http://tonysyu.github.com/mpltools/auto_examples/index.html > > > Download > -------- > > You can grab the 0.1 release on PyPI: > > http://pypi.python.org/pypi/mpltools/0.1 > > or clone the repo on github: > > https://github.com/tonysyu/mpltools.git > > > Contributors > ------------ > > Thanks the following people for reporting bugs and contributing fixes and > enhancements: > > - Alex Arsenovic > - Guillaume Calmettes > - Huy Nguyen > - Sergey Karayev > > Special thanks to Alex, who came up with an early implementation of > stylesheets that started me down this path. > > Neat work, Tony! I especially like the errorfill feature: http://tonysyu.github.com/mpltools/auto_examples/special/plot_errorfill.html#example-special-plot-errorfill-py Ben Root |
From: Tony Yu <ts...@gm...> - 2012-07-10 17:45:31
|
On Tue, Jul 10, 2012 at 1:10 PM, Benjamin Root <ben...@ou...> wrote: > > > On Tue, Jul 10, 2012 at 12:58 PM, Tony Yu <ts...@gm...> wrote: > >> Announcement: mpltools 0.1 >> ========================== >> >> mpltools is a package of tools for matplotlib. For the most part, these >> tools are only loosely-connected in functionality, but there are two that >> may prove particularly useful: >> >> Styles and plot2rst >> ------------------- >> >> The `style` package provides a simple way to define and reuse >> matplotlibrc-like config files. For example, there's an included style that >> mimics R's plotting package, ggplot. You can use this style by calling:: >> >> from mpltools import style >> style.use('ggplot') >> >> (Thanks to Huy Nguyen for these settings.) >> >> The second tool of note is `plot2rst`, which provides a simple way to >> generate (Sphinx-flavored) reStructuredText examples from normal python >> files. See the Getting Started page and `plot2rst` example for details: >> >> http://tonysyu.github.com/mpltools/getting_started.html >> >> http://tonysyu.github.com/mpltools/auto_examples/sphinx/plot_plot2rst.html >> >> >> Other tools >> ----------- >> >> This package provides other tools for tweaking colors, layouts, etc. The >> easiest way to get started is to look at the example gallery: >> >> http://tonysyu.github.com/mpltools/auto_examples/index.html >> >> >> Download >> -------- >> >> You can grab the 0.1 release on PyPI: >> >> http://pypi.python.org/pypi/mpltools/0.1 >> >> or clone the repo on github: >> >> https://github.com/tonysyu/mpltools.git >> >> >> Contributors >> ------------ >> >> Thanks the following people for reporting bugs and contributing fixes and >> enhancements: >> >> - Alex Arsenovic >> - Guillaume Calmettes >> - Huy Nguyen >> - Sergey Karayev >> >> Special thanks to Alex, who came up with an early implementation of >> stylesheets that started me down this path. >> >> > Neat work, Tony! I especially like the errorfill feature: > http://tonysyu.github.com/mpltools/auto_examples/special/plot_errorfill.html#example-special-plot-errorfill-py > > Ben Root > > Thanks Ben! Like a lot of things in the package, that's a fairly simple function, but I just wanted a simple interface to do it. Cheers, -Tony |
From: Tony Yu <ts...@gm...> - 2012-07-12 13:42:25
|
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 |
From: Damon M. <dam...@gm...> - 2012-07-12 13:45:30
|
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 |
From: Damon M. <dam...@gm...> - 2012-07-10 17:50:13
|
On Tue, Jul 10, 2012 at 01:44:41PM -0400, Tony Yu wrote: > On Tue, Jul 10, 2012 at 1:10 PM, Benjamin Root <ben...@ou...> wrote: > > > > > > > On Tue, Jul 10, 2012 at 12:58 PM, Tony Yu <ts...@gm...> wrote: > > > >> Announcement: mpltools 0.1 > >> ========================== > >> > >> mpltools is a package of tools for matplotlib. For the most part, these > >> tools are only loosely-connected in functionality, but there are two that > >> may prove particularly useful: > >> > >> Styles and plot2rst > >> ------------------- > >> > >> The `style` package provides a simple way to define and reuse > >> matplotlibrc-like config files. For example, there's an included style that > >> mimics R's plotting package, ggplot. You can use this style by calling:: > >> > >> from mpltools import style > >> style.use('ggplot') > >> > >> (Thanks to Huy Nguyen for these settings.) > >> > >> The second tool of note is `plot2rst`, which provides a simple way to > >> generate (Sphinx-flavored) reStructuredText examples from normal python > >> files. See the Getting Started page and `plot2rst` example for details: > >> > >> http://tonysyu.github.com/mpltools/getting_started.html > >> > >> http://tonysyu.github.com/mpltools/auto_examples/sphinx/plot_plot2rst.html > >> > >> > >> Other tools > >> ----------- > >> > >> This package provides other tools for tweaking colors, layouts, etc. The > >> easiest way to get started is to look at the example gallery: > >> > >> http://tonysyu.github.com/mpltools/auto_examples/index.html > >> > >> > >> Download > >> -------- > >> > >> You can grab the 0.1 release on PyPI: > >> > >> http://pypi.python.org/pypi/mpltools/0.1 > >> > >> or clone the repo on github: > >> > >> https://github.com/tonysyu/mpltools.git > >> > >> > >> Contributors > >> ------------ > >> > >> Thanks the following people for reporting bugs and contributing fixes and > >> enhancements: > >> > >> - Alex Arsenovic > >> - Guillaume Calmettes > >> - Huy Nguyen > >> - Sergey Karayev > >> > >> Special thanks to Alex, who came up with an early implementation of > >> stylesheets that started me down this path. > >> > >> > > Neat work, Tony! I especially like the errorfill feature: > > http://tonysyu.github.com/mpltools/auto_examples/special/plot_errorfill.html#example-special-plot-errorfill-py > > > > Ben Root > > > > > Thanks Ben! Like a lot of things in the package, that's a fairly simple > function, but I just wanted a simple interface to do it. > > Cheers, > -Tony Would there be any interest in porting some of that functionality into the main mpl codebase? Like Ben said, that error function is nifty... :) -- Damon McDougall http://damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom |
From: John H. <jd...@gm...> - 2012-07-10 17:53:08
|
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. |
From: Tony Yu <ts...@gm...> - 2012-07-10 21:37:38
|
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). As for porting the stylesheet implementation: Currently, the style files must be ConfigObj-readable files (which has a different syntax than matplotlibrc files). I've been planning to rewrite the implementation to use either file-type, but it may be best to just leave things as-is in mpltools, and create a matplotlib PR that uses matplotlibrc-style files. Right now, matplotlib's rc-machinery is not easily reusable: I would want to wait until after PR 861, which helps a bit: https://github.com/matplotlib/matplotlib/pull/861 There may need to be some more refactoring on that front before styles are added to the mainline, but I'm happy to help. Cheers, -Tony |
From: Damon M. <dam...@gm...> - 2012-07-11 15:09:36
|
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 |
From: John H. <jd...@gm...> - 2012-07-11 15:24:04
|
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 |
From: Damon M. <dam...@gm...> - 2012-07-11 17:53:24
|
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 |
From: Benjamin R. <ben...@ou...> - 2012-07-11 15:27:56
|
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 |
From: Tony Yu <ts...@gm...> - 2012-07-11 17:12:23
|
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 |
From: Benjamin R. <ben...@ou...> - 2012-07-11 18:28:51
|
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 |
From: Tony Yu <ts...@gm...> - 2012-07-12 00:34:09
|
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 > > |
From: Damon M. <dam...@gm...> - 2012-07-12 13:28:21
|
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 |
From: Damon M. <dam...@gm...> - 2012-07-12 19:33:30
|
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 |
From: Benjamin R. <ben...@ou...> - 2012-07-13 12:58:25
|
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 |
From: John H. <jd...@gm...> - 2012-07-13 13:11:07
|
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. |
From: Damon M. <dam...@gm...> - 2012-07-13 23:01:53
|
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 |
From: Benjamin R. <ben...@ou...> - 2012-07-14 01:56:53
|
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 |
From: John H. <jd...@gm...> - 2012-07-16 19:07:37
|
On Tue, Jul 10, 2012 at 11:58 AM, Tony Yu <ts...@gm...> wrote: > Announcement: mpltools 0.1 > ========================== > > mpltools is a package of tools for matplotlib. For the most part, these > tools are only loosely-connected in functionality, but there are two that > may prove particularly useful: > > Styles and plot2rst > ------------------- > > Tony, is there a way to "switch" styles rather than chain them. Eg, if I do: import mpltools.style as style style.use('ieee.transaction') ...make_a_plot_... style.use('ggplot') . ..make_a_plot_... I seem to get the chained behavior of the second style updating the first. I'd like to use this in a demo context where I can illustrate the styles separately, so it would be nice to go back to the defaults. Interestingly, I tried to do: import matplotlib matplotlib.rc_file_defaults() plt.close('all') hist(rand(10000), 100) but that simply stopped figures from raising all together (I don't think this is related to mpltools, but to something funny going on on my system). So in summary, it would be nice to be able to do something like: style.use('default') or: style.reset() which would take you back to a clean slate. |
From: Tony Yu <ts...@gm...> - 2012-07-16 22:07:46
|
On Mon, Jul 16, 2012 at 3:07 PM, John Hunter <jd...@gm...> wrote: > > > On Tue, Jul 10, 2012 at 11:58 AM, Tony Yu <ts...@gm...> wrote: > >> Announcement: mpltools 0.1 >> ========================== >> >> mpltools is a package of tools for matplotlib. For the most part, these >> tools are only loosely-connected in functionality, but there are two that >> may prove particularly useful: >> >> Styles and plot2rst >> ------------------- >> >> > Tony, is there a way to "switch" styles rather than chain them. Eg, if I > do: > > import mpltools.style as style > style.use('ieee.transaction') > ...make_a_plot_... > style.use('ggplot') > . ..make_a_plot_... > > I seem to get the chained behavior of the second style updating the first. > I'd like to use this in a demo context where I can illustrate the styles > separately, so it would be nice to go back to the defaults. > > Interestingly, I tried to do: > > import matplotlib > matplotlib.rc_file_defaults() > plt.close('all') > hist(rand(10000), 100) > > but that simply stopped figures from raising all together (I don't think > this is related to mpltools, but to something funny going on on my system). > > So in summary, it would be nice to be able to do something like: > > style.use('default') > > or: > > style.reset() > > which would take you back to a clean slate. > > I've been using plt.rcdefaults() for that purpose. Does that work for you? -Tony |
From: Tony Yu <ts...@gm...> - 2012-07-16 22:38:15
|
On Mon, Jul 16, 2012 at 6:06 PM, Tony Yu <ts...@gm...> wrote: > > > On Mon, Jul 16, 2012 at 3:07 PM, John Hunter <jd...@gm...> wrote: > >> >> >> On Tue, Jul 10, 2012 at 11:58 AM, Tony Yu <ts...@gm...> wrote: >> >>> Announcement: mpltools 0.1 >>> ========================== >>> >>> mpltools is a package of tools for matplotlib. For the most part, these >>> tools are only loosely-connected in functionality, but there are two that >>> may prove particularly useful: >>> >>> Styles and plot2rst >>> ------------------- >>> >>> >> Tony, is there a way to "switch" styles rather than chain them. Eg, if >> I do: >> >> import mpltools.style as style >> style.use('ieee.transaction') >> ...make_a_plot_... >> style.use('ggplot') >> . ..make_a_plot_... >> >> I seem to get the chained behavior of the second style updating the >> first. I'd like to use this in a demo context where I can illustrate the >> styles separately, so it would be nice to go back to the defaults. >> >> Interestingly, I tried to do: >> >> import matplotlib >> matplotlib.rc_file_defaults() >> plt.close('all') >> hist(rand(10000), 100) >> >> but that simply stopped figures from raising all together (I don't think >> this is related to mpltools, but to something funny going on on my system). >> >> So in summary, it would be nice to be able to do something like: >> >> style.use('default') >> >> or: >> >> style.reset() >> >> which would take you back to a clean slate. >> >> > I've been using plt.rcdefaults() for that purpose. Does that work for you? > > -Tony > Err, maybe I read your question wrong. Were you just suggesting that I wrap `matplotlib.rc_file_defaults()` in a new function called `style.reset()`, or were you suggesting a function that does something different than `rc_file_defaults`? -Tony |
From: todd r. <tod...@gm...> - 2012-07-17 11:25:46
|
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 |