matplotlib-devel Mailing List for matplotlib (Page 3)

On Tue, Jul 10, 2012 at 8:06 PM, Benjamin Root <ben...@ou...> wrote:
> On Tuesday, July 10, 2012, Mike Kaufman wrote:
>>
>> 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.
For reference, I believe Ben's referring to #697 [1], for which I provided a
possible implementation, which has the automagic concatenation you seek.
1. https://github.com/matplotlib/matplotlib/issues/697
best,
-- 
Paul Ivanov
314 address only used for lists, off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

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

On Tue, Jul 10, 2012 at 4:15 PM, Amy Dyer <ox...@gm...> wrote:
> Hi everyone,
>
> We're part of the summer 2012 batch at Hackerschool (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
Thanks!
Ben Root

Hi everyone,
We're part of the summer 2012 batch at Hackerschool (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

The standard RC parameters handling in Matplotlib has always troubled me. The 
syntax rc('figure.subplot', top=0.9) is not very conveniet if one wants to 
change a singe property. Direct rcParams['figure.subplot.top'] seems better 
suited in this case.
However, as the dots are already used to indicate grouping in RC, it seems 
very natural to use the syntax like:
rc.figure.subplot.top = 0.9
In my opinion this is very elegant, efficient and much Pythonic approach.
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).
Best regrds,
Maciek
-- 
Maciek Dems http://dems.art.pl/ 

On Tue, Jul 10, 2012 at 8:54 AM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <ef...@ha...> wrote:
>>
>> Is there any good reason *not* to delete support for Qt3 from master?
>> Is anyone who is using it likely to be able to upgrade to the next mpl
>> release, and yet *not* be able to install Qt4 and its bindings? Note
>> that ipython no longer supports Qt3.
>>
>> Eric
>>
>
> CentOS5 and RHEL5 both have qt3 as part of the stock install (although it
> does look like qt4 is available). CentOS6 and RHEL6 seem to have qt4 as
> default, with pyqt as well.
>
> Personally, I see no real reason to get rid of it quite yet as it doesn't
> seem to be much of a support burden -- yet. If anything, we might want to
> consider putting deprecation notices for that backend in the next release.
I also think its coming up on time to retire the Qt-3 backend, but
perhaps a deprecation notice in mpl-1.2 and removal in mpl-1.3 would
be appropriate. Then again, if mpl-1.2 supports python3, maybe that
would be a good time to delete the Qt3 backend, since there is no
python-3 binding for Qt3.
By the way, Qt-5 is expected in September. Hopefully it won't require
a dedicated backend, it sounds like PyQt4 will support Qt5's QtCore
and QtGui libraries.
Darren

On Tue, Jul 10, 2012 at 3:54 AM, Eric Firing <ef...@ha...> wrote:
> Is there any good reason *not* to delete support for Qt3 from master?
> Is anyone who is using it likely to be able to upgrade to the next mpl
> release, and yet *not* be able to install Qt4 and its bindings? Note
> that ipython no longer supports Qt3.
>
> Eric
>
>
CentOS5 and RHEL5 both have qt3 as part of the stock install (although it
does look like qt4 is available). CentOS6 and RHEL6 seem to have qt4 as
default, with pyqt as well.
Personally, I see no real reason to get rid of it quite yet as it doesn't
seem to be much of a support burden -- yet. If anything, we might want to
consider putting deprecation notices for that backend in the next release.
Ben Root

Is there any good reason *not* to delete support for Qt3 from master? 
Is anyone who is using it likely to be able to upgrade to the next mpl 
release, and yet *not* be able to install Qt4 and its bindings? Note 
that ipython no longer supports Qt3.
Eric

On Mon, Jul 9, 2012 at 4:34 PM, Benjamin Root <ben...@ou...> wrote:
>
>
> On Sat, Jul 7, 2012 at 7:30 PM, Amit Aronovitch <aro...@gm...>wrote:
>
>>
>>
<-- snipped (sent as issue #997) -->
>>
> I am always a fan of people who test and design their methods against edge
> cases like these, so my hat is off to you.
>
FTR: this was not a case of testing, but of hacking:
I had some code using scipy's delaunay interpolator, and I had to provide
fallback functionality for a machine that does not have a recent scipy
installed (luckily, it had matplotlib :-) ).
Since the sample set was irregular (not a grid) - the easiest (though
inefficient) fix was to loop over the set and use 1x1 grids. At this point
I hit this issue...
> I would suggest putting together a pull request so that we can properly
> test the potential impact such a change could have.
>
>
Done.
 thanks,
 Amit

On Sat, Jul 7, 2012 at 7:30 PM, Amit Aronovitch <aro...@gm...>wrote:
>
> The current implementation of Delaunay interpolator returns NaN for grids
> whose x or y has dimension 1 (i.e. when you try to interpolate along a
> horizontal/vertical line, or in a single point). See example below.
>
> By looking at the code, it seems that this can be fixed by simple
> rearrangement of calculations.
> Suggested patch provided here:
> https://github.com/AmitAronovitch/matplotlib/commit/f312d864da9c72681eb3db3b5920ae64793c713e(let me know if you want a pull request).
> The suggested implementation is almost identical. It might actually
> perform faster in some cases (there is one less multiplication op in the
> inner loop). There might be some differences in accuracy, but I believe
> they should only become observable in cases where the grid size is very
> large (which would probably cause memory problems anyway).
>
> Example (before suggested patch):
>
> >>> from matplotlib.delaunay import Triangulation
> >>> tri = Triangulation([0,10,10,0],[0,0,10,10])
> >>> lin = tri.linear_interpolator([1,10,5,2.0])
> >>> # 2x2 grid works fine
> >>> lin[3:6:2j,1:4:2j]
> array([[ 1.6, 3.1],
> [ 1.9, 2.8]])
> >>> # but not when 1x2, 2x1, 1x1:
> >>> lin[3:6:2j,1:1:1j]
> array([[ nan],
> [ nan]])
> >>> lin[3:3:1j,1:1:1j]
> array([[ nan]])
> >>>
>
> After suggested patch:
>
> >>> from matplotlib.delaunay import Triangulation
> >>> tri = Triangulation([0,10,10,0],[0,0,10,10])
> >>> lin = tri.linear_interpolator([1,10,5,2.0])
> >>> # 2x2 grid: same same
> >>> lin[3:6:2j,1:4:2j]
> array([[ 1.6, 3.1],
> [ 1.9, 2.8]])
> >>> # but these work now
> >>> lin[3:6:2j,1:1:1j]
> array([[ 1.6],
> [ 1.9]])
> >>> lin[3:3:1j,1:1:1j]
> array([[ 1.6]])
> >>>
>
>
I am always a fan of people who test and design their methods against edge
cases like these, so my hat is off to you. I would suggest putting
together a pull request so that we can properly test the potential impact
such a change could have.
Thanks!
Ben Root

The current implementation of Delaunay interpolator returns NaN for grids
whose x or y has dimension 1 (i.e. when you try to interpolate along a
horizontal/vertical line, or in a single point). See example below.
By looking at the code, it seems that this can be fixed by simple
rearrangement of calculations.
Suggested patch provided here:
https://github.com/AmitAronovitch/matplotlib/commit/f312d864da9c72681eb3db3b5920ae64793c713e(let
me know if you want a pull request).
The suggested implementation is almost identical. It might actually perform
faster in some cases (there is one less multiplication op in the inner
loop). There might be some differences in accuracy, but I believe they
should only become observable in cases where the grid size is very large
(which would probably cause memory problems anyway).
Example (before suggested patch):
>>> from matplotlib.delaunay import Triangulation
>>> tri = Triangulation([0,10,10,0],[0,0,10,10])
>>> lin = tri.linear_interpolator([1,10,5,2.0])
>>> # 2x2 grid works fine
>>> lin[3:6:2j,1:4:2j]
array([[ 1.6, 3.1],
 [ 1.9, 2.8]])
>>> # but not when 1x2, 2x1, 1x1:
>>> lin[3:6:2j,1:1:1j]
array([[ nan],
 [ nan]])
>>> lin[3:3:1j,1:1:1j]
array([[ nan]])
>>>
After suggested patch:
>>> from matplotlib.delaunay import Triangulation
>>> tri = Triangulation([0,10,10,0],[0,0,10,10])
>>> lin = tri.linear_interpolator([1,10,5,2.0])
>>> # 2x2 grid: same same
>>> lin[3:6:2j,1:4:2j]
array([[ 1.6, 3.1],
 [ 1.9, 2.8]])
>>> # but these work now
>>> lin[3:6:2j,1:1:1j]
array([[ 1.6],
 [ 1.9]])
>>> lin[3:3:1j,1:1:1j]
array([[ 1.6]])
>>>

On 06.07.2012, at 3:49PM, Damon McDougall wrote:
>> 
>> When I tested on Mac OS X 10.6 I found that most unit tests were somehow 
>> missing. Rather than try to diagnose the problem, I built a new binary 
>> on 10.6, confirmed that it installed properly (with all unit tests) on 
>> 10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary.
>> 
>> The same test I mentioned in my previous post still fails using the new 
>> binary, on both 10.6 and 10.7.
>> 
>> -- Russell
>> 
> 
> I did a git checkout of the v1.1.1 tag and compiled a 64-bit version. I
> have attached output from the following command:
> 
> python -c "import matplotlib as m ; m.test(verbosity=1)"
> 
> Note that some of the tests fail with satuses: KEFKK.
> I have the following requirements installed:
> 
> nose: version 1.1.2
> PIL: version 1.1.7
> ghsotscript: version 9.05
> inkscape: 0.48.3.1
> 
> All of these were installed using the latest version of macports.
> Is there anything I can do to improve the output of the tests?
I see the same 3 known failures building with fink and the same versions of the above 
dependencies, and also get the already mentioned Stix failure. Everything else succeeds 
on 10.5, but I get a different inkscape error on 10.7:
+++++
IOError: Conversion command failed:
inkscape -z /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2.svg --export-png /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2_svg.png
Standard output:
Background RRGGBBAA: ffffff00
Area 0:0:720:540 exported to 720 x 540 pixels (90 dpi)
Bitmap saved as: /scratch.noindex/fink.build/matplotlib-py27-1.1.1-1/matplotlib-1.1.1/result_images/test_legend/legend_auto2_svg.png
Standard error:
(inkscape:25527): libgnomevfs-WARNING **: Unable to create ~/.gnome2 directory: Permission denied
File display/nr-arena-item.cpp line 147 (?): Assertion child->parent == NULL failed
**
ERROR:sp-clippath.cpp:308:void sp_clippath_hide(SPClipPath*, unsigned int): code should not be reached
Emergency save activated!
Emergency save completed. Inkscape will close now.
If you can reproduce this crash, please file a bug at www.inkscape.org
with a detailed description of the steps leading to the crash, so we can fix it.
** Message: Error: Inkscape encountered an internal error and will close now.
+++++
This is obviously an inscape bug to be reported it to its respective maintainers. 
I found that on the Inkscape web site 0.48.2 is advertised as the stable release, 
so I tried downgrading to that version, but just get a similar crash on a different file.
Cheers,
					Derek

On Tue, Jul 3, 2012 at 11:18 AM, Ryan May <rm...@gm...> wrote:
> On Tue, Jul 3, 2012 at 10:03 AM, Tony Yu <ts...@gm...> wrote:
> >
> >
> > On Tue, Jul 3, 2012 at 10:22 AM, Ryan May <rm...@gm...> wrote:
> >>
> >> On Tue, Jul 3, 2012 at 9:14 AM, Tony Yu <ts...@gm...> wrote:
> >> > On Mon, Jul 2, 2012 at 11:42 PM, Tony Yu <ts...@gm...> wrote:
>
> >> >> I finally had some time to revisit this issue. It seems that
> subprocess
> >> >> PIPEs have fairly limited buffers [1] (also see docs for
> >> >> `subprocess.Popen.communicate` [2]) and ffmpeg tends to generate a
> >> >> decent
> >> >> amount of output to stderr. A simple solution is to redirect stderr
> to
> >> >> a
> >> >> temporary file. This change fixes the issue on my system.
> >> >>
> >> >> If this bug is reproducible, I can submit a PR. The temporary file
> here
> >> >> could be created using tempfile so it gets cleaned up automatically,
> or
> >> >> maybe a more permanent log file for debugging. Thoughts?
> >> >>
> >> >> -Tony
> >> >>
> >> >> [1]
> >> >>
> >> >>
> http://thraxil.org/users/anders/posts/2008/03/13/Subprocess-Hanging-PIPE-is-your-enemy/
> >> >>
> >> >> [2]
> >> >>
> >> >>
> http://docs.python.org/library/subprocess.html#subprocess.Popen.communicate
> >> >>
> >> >
> >> > And just to clarify: My original email mentioned that saving would
> hang
> >> > only
> >> > when `streamplot` was used to create the figure. It turns out that
> >> > ffmpeg
> >> > prints more output (keyframes?) for more complex images, so when I ran
> >> > simpler plots, they didn't produce enough output to fill the
> subprocess
> >> > `PIPE` (although they would eventually).
> >> >
> >> > Also, theres's a simpler fix than piping ffmpeg output to a file: Just
> >> > set
> >> > `-loglevel quiet` in the ffmpeg command.
> >> >
> >> > -Tony
> >>
> >> It's not a bad idea to have it logged to a file in a temp directory.
> >> We could potentially just do this if debug is set to verbose, however,
> >> and just use -loglevel quiet otherwise. Can you manage PR for this or
> >> do I need to?
> >>
> >> Ryan
> >>
> >
> > Hey Ryan,
> >
> > If you have time, that'd be great. Otherwise, I should have some time at
> the
> > end of the week to submit a PR.
> >
> > -Tony
> >
>
> I might be able to squeeze it in. If you don't see anything by the end
> of the week, hit me up.
>
> Ryan
>
>
Hey Ryan,
I didn't see a PR for this issue, so I just added a fix:
https://github.com/matplotlib/matplotlib/pull/989
As mentioned before, the PR suppresses logging in ffmpeg under normal
circumstances. When the verbosity level is set to debug, however, the
subprocess output (stdout + stderr) are piped to `sys.stdout`. This is
where verbose reports are posted, so I figured that was the best place (oh,
actually, I guess could have piped to `verbose.fileo`).
If you feel the debug output should go to a file instead, let me know.
Cheers,
-Tony

In article <m2t...@en...teway>,
 Jouni K. Seppänen <jk...@ik...> wrote:
> Russell Owen <ro...@uw...> writes:
> 
> > By the way: I installed ghostscript from source and Inkscape
> > application from binary. More tests pass, but many still show K. My
> > guess is that matplotlib can see ghostscript but not the Inkscape
> > application (no surprise). Inkscape has too many dependencies for me
> > to want to try to build it from source.
> 
> The following should help matplotlib find Inkscape:
> 
> PATH=$PATH:/Applications/Inkscape.app/Contents/Resources/bin \
> python -c 'import matplotlib; matplotlib.test(1)'
Yes, thanks. I figured that out this morning and reran the tests for the 
64-bit matplotlib on 10.7. Almost everything passes now. Just a few K 
and one actual failure that appears to be nothing to worry about (though 
a failing unit test is always worrisome.
I'm still wondering how I managed to build a binary installer that 
installed the test packages on 10.7 and failed to install them on 10.6, 
but I don't have time to investigate.
-- Russell

On Thu, Jul 05, 2012 at 07:43:39PM +0000, Russell E. Owen wrote:
> In article <EF3...@uw...>,
> Russell Owen <ro...@uw...> wrote:
> 
> > I just uploaded the Mac binaries.
> > 
> > Several minor concerns:
> > - Many unit tests failed on Mac OS X 10.4 (which is where I build the 10.3.9 
> > version) due to "too many files open", but the same binary looks fine on 
> > 10.5.
> > - The 64-bit version (10.6 and later) had one unexpected failure on 10.7 (I 
> > have not yet had time to test it on 10.6)...
> 
> When I tested on Mac OS X 10.6 I found that most unit tests were somehow 
> missing. Rather than try to diagnose the problem, I built a new binary 
> on 10.6, confirmed that it installed properly (with all unit tests) on 
> 10.6 and 10.7, then uploaded it to replace the earlier 10.6 binary.
> 
> The same test I mentioned in my previous post still fails using the new 
> binary, on both 10.6 and 10.7.
> 
> -- Russell
> 
I did a git checkout of the v1.1.1 tag and compiled a 64-bit version. I
have attached output from the following command:
python -c "import matplotlib as m ; m.test(verbosity=1)"
Note that some of the tests fail with satuses: KEFKK.
I have the following requirements installed:
nose: version 1.1.2
PIL: version 1.1.7
ghsotscript: version 9.05
inkscape: 0.48.3.1
All of these were installed using the latest version of macports.
Is there anything I can do to improve the output of the tests?
-- 
Damon McDougall
http://damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom