matplotlib-devel Mailing List for matplotlib

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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.

Adam Mercer wrote:
> On Tue, Jul 28, 2009 at 05:14, Jeff Whitaker<js...@fa...> 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/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Tue, Jul 28, 2009 at 05:14, Jeff Whitaker<js...@fa...> 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

On Mon, Jul 27, 2009 at 8:14 PM, Jeff Whitaker<js...@fa...> wrote:
> Chris Petrich wrote:
>>
>> Hi,
>>
>> I get a Topology Exception with GEOS 3.1:
>>
>> import mpl_toolkits.basemap as bm
>> print "GEOS version: ", bm._geoslib.__geos_version__
>> print "basemap version: ", bm.__version__
>>
>> m = bm.Basemap(width=12000000,height=8000000, \
>>      resolution='l',projection='laea',\
>>      lat_0=55,lon_0=175.)
>>
>> output:
>>
>> GEOS version: 3.1.0-CAPI-1.5.0
>> basemap version: 0.99.3
>> GEOS_ERROR: TopologyException: found non-noded intersection between
>> 3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06
>> 1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07
>> Segmentation fault
>>
>>
>> Any solutions?
>> cheers
>>
>> Chris
>>
>>
>
> 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.
>
> -Jeff
>
Thanks, Jeff,
that was it.
I had both geos 3.1 and 2.2.3 installed in /usr. basemap found 3.1
during build/installation while _libgeos tried to import 2.2.3 at run
time (this became obvious after I removed the 2.2.3 libraries).
Removed libgeos 2.2.3 and "python setup.py install"-ed basemap 0.99.3
from a fresh tar ball, works like a charm now!
I appreciate the effort you put into developing basemap. The result is awesome.
cheers
Chris

Chris Petrich wrote:
> Hi,
>
> I get a Topology Exception with GEOS 3.1:
>
> import mpl_toolkits.basemap as bm
> print "GEOS version: ", bm._geoslib.__geos_version__
> print "basemap version: ", bm.__version__
>
> m = bm.Basemap(width=12000000,height=8000000, \
> resolution='l',projection='laea',\
> lat_0=55,lon_0=175.)
>
> output:
>
> GEOS version: 3.1.0-CAPI-1.5.0
> basemap version: 0.99.3
> GEOS_ERROR: TopologyException: found non-noded intersection between
> 3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06
> 1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07
> Segmentation fault
>
>
> Any solutions?
> cheers
>
> Chris
>
> 
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.
-Jeff

Hi,
I get a Topology Exception with GEOS 3.1:
import mpl_toolkits.basemap as bm
print "GEOS version: ", bm._geoslib.__geos_version__
print "basemap version: ", bm.__version__
m = bm.Basemap(width=12000000,height=8000000, \
 resolution='l',projection='laea',\
 lat_0=55,lon_0=175.)
output:
GEOS version: 3.1.0-CAPI-1.5.0
basemap version: 0.99.3
GEOS_ERROR: TopologyException: found non-noded intersection between
3.03025e+06 1.45852e+07, 3.02518e+06 1.45831e+07 and 3.02379e+06
1.45823e+07, 3.02937e+06 1.45857e+07 3.02519e+06 1.45831e+07
Segmentation fault
Any solutions?
cheers
Chris