matplotlib-devel Mailing List for matplotlib

On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> dam...@gm...> wrote:
>>
>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>> complicated, either. I'd be more than happy to port it over later today
>> when I get bored of typing up my thesis. It'll probably only take me
>> about 30 minutes.
>>
>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>> evening (British Summer (hah!) Time).
>>
>
>
> While it is a nice graph, I am not sure that the use case is common enough
> to justify a new plotting method. One can get the same result with:
>
>
> In [68]: x = np.linspace(0, 2 * np.pi)
>
> In [69]: y_sin = np.sin(x)
>
> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>
> In [71]: plot(x, y_sin)
> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
>
> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> facecolor='red', alpha=0.5)
> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
>
> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> adding a new plotting method, perhaps we would be better off with a helper
> method to create the xs and ys for fill_between
>
> xs, ys = mlab.pad_line(x, y, 0.2)
> fill_between(xs, ys)
>
> JDH
>
I could definitely agree with a pad_line() function. We might want to
revisit the issue of how much visibility the mlab module should get in the
documentation (it currently doesn't get much at all). My whole take on
mlab was that it was a left-over from the days of working around issues in
NumPy and SciPy and that it was being slowly phased out. As for other
possible locations, cbook feels like it is more for the devs than for the
users, and adding it to pyplot would render the whole purpose of creating
this function as opposed to errorfill moot.
As an additional point about such a pad_line function, it should probably
be nice to mirror the errorbar() functionality to allow not only a constant
error, but also a N, Nx1, or 2xN array of +/- error. (note that errorbar()
for the 2xN array case does -row1 and +row2).
Cheers!
Ben Root

On Wed, Jul 11, 2012 at 10:23:32AM -0500, John Hunter wrote:
> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <dam...@gm...
> > wrote:
> >
> > Well, as Ben said, that error fill plot is neato! It doesn't look too
> > complicated, either. I'd be more than happy to port it over later today
> > when I get bored of typing up my thesis. It'll probably only take me
> > about 30 minutes.
> >
> > If nobody is opposed to this idea, I'll go ahead and submit a PR this
> > evening (British Summer (hah!) Time).
> >
> 
> 
> While it is a nice graph, I am not sure that the use case is common enough
> to justify a new plotting method. One can get the same result with:
> 
> 
> In [68]: x = np.linspace(0, 2 * np.pi)
> 
> In [69]: y_sin = np.sin(x)
> 
> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
> 
> In [71]: plot(x, y_sin)
> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
> 
> In [72]: fill_between(np.concatenate([x, x[::-1]]), err, facecolor='red',
> alpha=0.5)
> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
> 
> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> adding a new plotting method, perhaps we would be better off with a helper
> method to create the xs and ys for fill_between
> 
> xs, ys = mlab.pad_line(x, y, 0.2)
> fill_between(xs, ys)
> 
> JDH
+1 on the helper function. That's probably a much less bloated of way of
doing it.
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Wed, Jul 11, 2012 at 11:27 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
>
>>
>>
>> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
>> dam...@gm...> wrote:
>>>
>>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>>> complicated, either. I'd be more than happy to port it over later today
>>> when I get bored of typing up my thesis. It'll probably only take me
>>> about 30 minutes.
>>>
>>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>>> evening (British Summer (hah!) Time).
>>>
>>
>>
>> While it is a nice graph, I am not sure that the use case is common
>> enough to justify a new plotting method. One can get the same result with:
>>
>>
>> In [68]: x = np.linspace(0, 2 * np.pi)
>>
>> In [69]: y_sin = np.sin(x)
>>
>> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>>
>> In [71]: plot(x, y_sin)
>> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
>>
>> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
>> facecolor='red', alpha=0.5)
>> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
>>
>> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
>> adding a new plotting method, perhaps we would be better off with a helper
>> method to create the xs and ys for fill_between
>>
>> xs, ys = mlab.pad_line(x, y, 0.2)
>> fill_between(xs, ys)
>>
>> JDH
>>
>
> At the very least, it should be added to the gallery. Also, one thing
> that might (or might not) get in the way of getting merged into mainline
> mpl is how well it interacts with legends. What does it produce in the
> legend?
>
> Ben Root
>
>
As I said before, it is a really simple function: I wrote `errorfill` just
to get an interface that is somewhat similar to `errorbar`. I tend to think
that the Axes object is a bit bloated, so I'm inclined to agree that it
might be best leave it out of matplotlib-proper. +1 on the gallery, though.
Ben: Good point about the legend-interaction. I just added a fix on github;
here's the result:
http://tonysyu.github.com/mpltools/auto_examples/special/plot_errorfill.html
Cheers,
-Tony

On Wed, Jul 11, 2012 at 11:23 AM, John Hunter <jd...@gm...> wrote:
>
>
> On Wed, Jul 11, 2012 at 10:09 AM, Damon McDougall <
> dam...@gm...> wrote:
>>
>> Well, as Ben said, that error fill plot is neato! It doesn't look too
>> complicated, either. I'd be more than happy to port it over later today
>> when I get bored of typing up my thesis. It'll probably only take me
>> about 30 minutes.
>>
>> If nobody is opposed to this idea, I'll go ahead and submit a PR this
>> evening (British Summer (hah!) Time).
>>
>
>
> While it is a nice graph, I am not sure that the use case is common enough
> to justify a new plotting method. One can get the same result with:
>
>
> In [68]: x = np.linspace(0, 2 * np.pi)
>
> In [69]: y_sin = np.sin(x)
>
> In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
>
> In [71]: plot(x, y_sin)
> Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
>
> In [72]: fill_between(np.concatenate([x, x[::-1]]), err,
> facecolor='red', alpha=0.5)
> Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
>
> Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
> adding a new plotting method, perhaps we would be better off with a helper
> method to create the xs and ys for fill_between
>
> xs, ys = mlab.pad_line(x, y, 0.2)
> fill_between(xs, ys)
>
> JDH
>
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 10:09 AM, Damon McDougall <dam...@gm...
> wrote:
>
> Well, as Ben said, that error fill plot is neato! It doesn't look too
> complicated, either. I'd be more than happy to port it over later today
> when I get bored of typing up my thesis. It'll probably only take me
> about 30 minutes.
>
> If nobody is opposed to this idea, I'll go ahead and submit a PR this
> evening (British Summer (hah!) Time).
>
While it is a nice graph, I am not sure that the use case is common enough
to justify a new plotting method. One can get the same result with:
 In [68]: x = np.linspace(0, 2 * np.pi)
 In [69]: y_sin = np.sin(x)
 In [70]: err = np.concatenate([y_sin + 0.2, y_sin[::-1] - 0.2])
 In [71]: plot(x, y_sin)
 Out[71]: [<matplotlib.lines.Line2D object at 0x96959ec>]
 In [72]: fill_between(np.concatenate([x, x[::-1]]), err, facecolor='red',
alpha=0.5)
 Out[72]: <matplotlib.collections.PolyCollection object at 0x962758c>
Admittedly the [::-1] thing is a bit counter-intuitive, but rather than
adding a new plotting method, perhaps we would be better off with a helper
method to create the xs and ys for fill_between
 xs, ys = mlab.pad_line(x, y, 0.2)
 fill_between(xs, ys)
JDH

On 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

Dnia wtorek, 10 lipca 2012 21:32:40 Maciek Dems pisze:
> In the attachment I include a path to the current git main repo, which
> enables this way of handling RC properties. I would appreciate very much if
> they were reviewed and included in the next release of Matplotlib (the
> patch is not particularly large).
I have posted the path to the github fork, as described in developer manual of 
matplotlib. The most recent changes are here:
http://github.com/macdems/matplotlib/compare/master...better-rc
Best regards,
Maciek
-- 
Maciek Dems http://dems.art.pl/en/

On 2012年07月10日 6:44 PM, Patrick Marsh wrote:
> Hi, All,
>
> When trying to call plt.show() to display a generate QuadMesh using the
> MacOSX backend, an error complaining about "TypeError: only length-1
> arrays can be converted to Python scalars" is generated. The following
> gist contains two files: 1) a self contained example that will generate
> the error and 2) the Traceback generated. For completeness, the full
> hash of the commit I'm using (pulled early today) is found in the first
> line of the second file.
>
> https://gist.github.com/3087990
>
> I should add that switching to using plt.contourf() instead of
> pcolormesh does not error. This error does not occur when using a
> different backend.
>
> I submitted an issue to the issue tracker, which can be found here:
> https://github.com/matplotlib/matplotlib/issues/1006
Thanks, but I closed it because it is a duplicate of #996.
Eric
>
>
> Patrick
>
>
> ---
> Patrick Marsh
> Ph.D. Candidate / Liaison to the HWT
> School of Meteorology / University of Oklahoma
> Cooperative Institute for Mesoscale Meteorological Studies
> National Severe Storms Laboratory
> http://www.patricktmarsh.com
>

Hi, All,
When trying to call plt.show() to display a generate QuadMesh using the MacOSX backend, an error complaining about "TypeError: only length-1 arrays can be converted to Python scalars" is generated. The following gist contains two files: 1) a self contained example that will generate the error and 2) the Traceback generated. For completeness, the full hash of the commit I'm using (pulled early today) is found in the first line of the second file.
https://gist.github.com/3087990
I should add that switching to using plt.contourf() instead of pcolormesh does not error. This error does not occur when using a different backend.
I submitted an issue to the issue tracker, which can be found here: https://github.com/matplotlib/matplotlib/issues/1006
Patrick
---
Patrick Marsh
Ph.D. Candidate / Liaison to the HWT
School of Meteorology / University of Oklahoma
Cooperative Institute for Mesoscale Meteorological Studies
National Severe Storms Laboratory
http://www.patricktmarsh.com

On Tuesday, July 10, 2012, Mike Kaufman wrote:
> On 7/10/12 4:18 PM, Benjamin Root wrote:
> >
> >
> > On Tue, Jul 10, 2012 at 4:15 PM, Amy Dyer <ox...@gm...<javascript:;>
> > <mailto:ox...@gm... <javascript:;>>> wrote:
> >
> > Hi everyone,
> >
> > We're part of the summer 2012 batch at Hackerschool
> > (www.hackerschool.com <http://www.hackerschool.com>) and we chose to
> > spend this week contributing to matplotlib. We already submitted a
> > handful of pull requests for bugs but we are looking for more to do.
> >
> > Are there any open issues or features you would like us to work on?
> >
> > - Amy, Vera, Beverly and Alan
> >
> >
> > Awesome!
> >
> > Here is a quick list of all github issues tagged with "wishlist":
> >
> >
> https://github.com/matplotlib/matplotlib/issues?labels=wishlist&page=1&state=open
> > <
> https://github.com/matplotlib/matplotlib/issues?labels=wishlist&page=1&state=open
> >
>
> I probably should at some point submit this as a wishlist item, but I
> thought I'd mention it here:
>
> The other day, I was looking to make a ylabel with text of two different
> colors (I wanted to use the ylabel in a twinx rather than a legend to
> show that two of three plots on an axis used a particular scale). See also:
>
>
> http://stackoverflow.com/questions/9169052/partial-coloring-of-text-in-matplotlib
>
> Unfortunately, I don't believe this solution is going to work in a
> xlabel or ylabel without finding the location of the ylabel and putting
> these concatenated text objects there.
>
> It would be nice to have the label and title methods take a Text object
> (and a list of text objects -- each of whom could supply a piece of
> different colored text) in addition to a string.
>
> A list of text objects would be automagically concatenated together. How
> to generalize alignment of multiple text objects? Haven't thought that
> far yet.
>
> Either that or develop some additional color markup (and a parser)
> inside a string. Admittedly a bigger project -- though probably a better
> solution.
>
> M
>
>
That is already a wishlist item. Feel free to comment on its discussion
thread with your ideas.
Ben Root

On 7/10/12 4:18 PM, Benjamin Root wrote:
>
>
> On Tue, Jul 10, 2012 at 4:15 PM, Amy Dyer <ox...@gm...
> <mailto:ox...@gm...>> wrote:
>
> Hi everyone,
>
> We're part of the summer 2012 batch at Hackerschool
> (www.hackerschool.com <http://www.hackerschool.com>) and we chose to
> spend this week contributing to matplotlib. We already submitted a
> handful of pull requests for bugs but we are looking for more to do.
>
> Are there any open issues or features you would like us to work on?
>
> - Amy, Vera, Beverly and Alan
>
>
> Awesome!
>
> Here is a quick list of all github issues tagged with "wishlist":
>
> https://github.com/matplotlib/matplotlib/issues?labels=wishlist&page=1&state=open
> <https://github.com/matplotlib/matplotlib/issues?labels=wishlist&page=1&state=open>
I probably should at some point submit this as a wishlist item, but I 
thought I'd mention it here:
The other day, I was looking to make a ylabel with text of two different 
colors (I wanted to use the ylabel in a twinx rather than a legend to 
show that two of three plots on an axis used a particular scale). See also:
http://stackoverflow.com/questions/9169052/partial-coloring-of-text-in-matplotlib
Unfortunately, I don't believe this solution is going to work in a 
xlabel or ylabel without finding the location of the ylabel and putting 
these concatenated text objects there.
It would be nice to have the label and title methods take a Text object 
(and a list of text objects -- each of whom could supply a piece of 
different colored text) in addition to a string.
A list of text objects would be automagically concatenated together. How 
to generalize alignment of multiple text objects? Haven't thought that 
far yet.
Either that or develop some additional color markup (and a parser) 
inside a string. Admittedly a bigger project -- though probably a better 
solution.
M