Re: [matplotlib-devel] basemap not working with GEOS 3.1

2009-07-28 Thread Adam Mercer
On Tue, Jul 28, 2009 at 05:14, Jeff Whitaker wrote:

> Chris:  This usually happens when you build mix different versions of
> geos, i.e. build with the 3.1 lib but the 2.2.3 headers, or link with
> the 3.1 shared lib and then have it pick up the 2.2.3 shared lib at run
> time.  Do you have two versions of geos on your system?  If so, make
> sure basemap is only finding one of them, both at build time and run time.

So does basemap support GEOS-3.1 now? I thought that it only worked
with 2.2.3? If so this is great news.

Cheers

Adam

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] basemap not working with GEOS 3.1

2009-07-28 Thread Jeff Whitaker
Adam Mercer wrote:
> On Tue, Jul 28, 2009 at 05:14, Jeff Whitaker wrote:
>
>   
>> Chris:  This usually happens when you build mix different versions of
>> geos, i.e. build with the 3.1 lib but the 2.2.3 headers, or link with
>> the 3.1 shared lib and then have it pick up the 2.2.3 shared lib at run
>> time.  Do you have two versions of geos on your system?  If so, make
>> sure basemap is only finding one of them, both at build time and run time.
>> 
>
> So does basemap support GEOS-3.1 now?

Yes.
>  I thought that it only worked
> with 2.2.3? If so this is great news.
>
> Cheers
>
> Adam
>   


-- 
Jeffrey S. Whitaker Phone  : (303)497-6313
Meteorologist   FAX: (303)497-6449
NOAA/OAR/PSD  R/PSD1Email  : [email protected]
325 BroadwayOffice : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] Including mathtex in matplotlib

2009-07-28 Thread Freddie Witherden
Hi,

I was thinking about the problem of including mathtex in matplotlib earlier 
and came up with an alternative means of 'solving' the problem.

Instead of hacking setup.py to install mathtex on the behalf of matplotlib it 
may be easier to leave it up to the user/packager to install mathtex.

While simplifying the code (not as many changed are need to the setup files) it 
also eliminates the problems associated with one package installing another 
package (matplotlib installing mathtex).

This could be done either through ones distribution package manger, standalone 
(getting the mathtex source) or just by following the instructions in 
lib/mathtex/INSTALL. (Checking out matplotlib also checks out the mathtex 
source into lib/mathtex.)

However, I am interested if this solution is acceptable to the matplotlib 
developers.

It may also be worth pointing out that mathtex is an optional dependency of 
matplotlib and is not required for matplotlib to function.

Regards, Freddie.

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


Re: [matplotlib-devel] improved performance for quiver

2009-07-28 Thread Eric Firing
Ray Speth wrote:
> I believe I have found a simple change that improves the rendering speed 
> of quiver plots, which can be quite slow for large vector fields. Based 
> on some profiling, the problem appears to stem from the use of numpy's 
> MaskedArrays in PolyCollection.set_verts. If I add the following line to 
> the top of the PolyCollection.set_verts function in collections.py:
> 
>   verts = np.asarray(verts)
> 
> I find that quiver plots are drawn about 3 times as quickly, going from 
> 2.6 seconds for a 125x125 field to 0.65 seconds. This does not seem to 
> break the use of MaskedArrays as inputs, and masked regions are still 
> hidden in the final plot. I do not know if this has any adverse effects 
> in other classes that inherit from PolyCollection.

I made a change in PolyCollection.set_verts that has the effect of your 
suggestion but without affecting masked argument inputs in general.  I 
also made a bunch of other changes in quiver.py to speed things up with 
or without masked inputs, but their net effect is minimal in practice; 
your suggestion was the key.  I get a factor of 2, not 3; I think this 
must be a difference in our machines, though.  In any case, I'm glad you 
found the time sink.

Eric

> 
> Using:
> python 2.6.2 on Windows XP
> numpy 1.3.0
> matplotlib 0.98.5.3, Qt4Agg backend
> 
> I do not know why iterating over MaskedArrays is so slow, but perhaps 
> this information can be used to speed up some other functions as well.
> 
> Ray Speth
> 
> --
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel