ANN: mpltools 0.1 release

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

···

On Tue, Jul 10, 2012 at 12:58 PM, Tony Yu <tsyu80@…287…> 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.

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

···

On Tue, Jul 10, 2012 at 1:10 PM, Benjamin Root <ben.root@…1304…> wrote:

On Tue, Jul 10, 2012 at 12:58 PM, Tony Yu <tsyu80@…287…> 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

Would there be any interest in porting some of that functionality into
the main mpl codebase? Like Ben said, that error function is nifty... :slight_smile:

···

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.root@...1304...> wrote:

>
>
> On Tue, Jul 10, 2012 at 12:58 PM, Tony Yu <tsyu80@...287...> 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

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

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.

···

On Tue, Jul 10, 2012 at 12:49 PM, Damon McDougall <damon.mcdougall@…287…> 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… :slight_smile:

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

···

On Tue, Jul 10, 2012 at 1:52 PM, John Hunter <jdh2358@…287…> wrote:

On Tue, Jul 10, 2012 at 12:49 PM, Damon McDougall <damon.mcdougall@…287…> 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… :slight_smile:

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.

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).

···

On Tue, Jul 10, 2012 at 05:36:50PM -0400, Tony Yu wrote:

On Tue, Jul 10, 2012 at 1:52 PM, John Hunter <jdh2358@...287...> wrote:

>
> On Tue, Jul 10, 2012 at 12:49 PM, Damon McDougall < > > damon.mcdougall@...287...> 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... :slight_smile:
>>
>>
>
> 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).

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

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:09 AM, Damon McDougall <damon.mcdougall@…287…> 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).

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:23 AM, John Hunter <jdh2358@…287…> wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…287…> 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

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:27 AM, Benjamin Root <ben.root@…1304…> wrote:

On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…287…> wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…287…> 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

+1 on the helper function. That's probably a much less bloated of way of
doing it.

···

On Wed, Jul 11, 2012 at 10:23:32AM -0500, John Hunter wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@...287... > > 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

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

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 11:23 AM, John Hunter <jdh2358@…287…> wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…287…> 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

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 :wink:

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

···

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@…1304…> wrote:

On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…287…> wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <damon.mcdougall@…287…> wrote:

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?

···

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@...1304...> wrote:

>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...287...> wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdougall@...287...> 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 :wink:

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
>
>

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

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 :wink:

-Tony

···

On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall <damon.mcdougall@…287…> wrote:

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@…1304…> wrote:

On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…287…> wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@…287…> 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 :wink:

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

Aha, the answer was 'yes, I was missing something'! :slight_smile:
Thanks.

···

On Thu, Jul 12, 2012 at 09:41:32AM -0400, Tony Yu wrote:

On Thu, Jul 12, 2012 at 9:28 AM, Damon McDougall > <damon.mcdougall@...287...>wrote:

> On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:
> > On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@...1304...> wrote:
> >
> > >
> > >
> > > On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...287...> > > wrote:
> > >
> > >>
> > >>
> > >> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@...287...> 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 :wink:
> >
> > 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 :wink:
-Tony

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

>
>
>
>>
>>
>>>
>>> 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 :wink:

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?

···

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@...1304...> wrote:
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...287...> wrote:
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdougall@...287...> wrote:

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

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 Thu, Jul 12, 2012 at 3:33 PM, Damon McDougall <damon.mcdougall@…287…> wrote:

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@…1304…> wrote:

On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@…287…> wrote:

On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > > > >> damon.mcdougall@…287…> 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 :wink:

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?

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 Jul 13, 2012, at 7:57 AM, Benjamin Root <ben.root@…1304…> 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 :wink:

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

···

On Wed, Jul 11, 2012 at 08:33:21PM -0400, Tony Yu wrote:

On Wed, Jul 11, 2012 at 2:28 PM, Benjamin Root <ben.root@...1304...> wrote:
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jdh2358@...287...> wrote:
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall < > >> damon.mcdougall@...287...> wrote:

--
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom