[matplotlib-devel] Should gc.set_alpha accept strings?
Hi everybody,
Should the set_alpha method of a graphics context accept a string (instead of a
number) as an argument? Currently, some backends (agg, ps, pdf) accept strings
such as "0.2", whereas others (svg, cairo, Mac OS X) do not. Usually that is
not a problem, since in almost all cases set_alpha is called with a number as
the argument. However, the example axes_zoom_effect.py, which was recently
added to examples/pylab_examples, has these lines:
prop_patches["alpha"]="0.2"
which causes a call to gc.set_alpha of the form gc.set_alpha("0.2"). Backends
that do not allow strings choke on that.
Whereas in general it may perhaps be useful to allow such strings, it adds
complexity to the code, and I don't see a good use case for it.
--Michiel.
--
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] plot argument handling
In svn 7298 I changed a key chunk of code that was working fine, so I would like to explain why I fixed it when it wasn't broken, and ask for review and testing, or at least keeping your eyes open for anything I may have overlooked. In the course of making the very simple change to support scalar arguments to plot (for plotting a single symbol), I found, as I have many times before, that the argument handling was rather complex, repetitive, and hard to follow. I couldn't resist seeing if I could simplify it, in the hope that this would make it easier to maintain. The result is a reduction in LOC and a codepath that to my eye, at least, is easier to follow. Eric -- ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Should gc.set_alpha accept strings?
I committed the original example into the svn, and I admit that I was
not careful with the code. I agree that the arguments should be float
(the doc does say that set_alpha takes float).
The example is now updated to use floats (svn r7300).
Regards,
-JJ
On Mon, Jul 27, 2009 at 9:15 AM, Michiel de Hoon wrote:
>
> Hi everybody,
>
> Should the set_alpha method of a graphics context accept a string (instead of
> a number) as an argument? Currently, some backends (agg, ps, pdf) accept
> strings such as "0.2", whereas others (svg, cairo, Mac OS X) do not. Usually
> that is not a problem, since in almost all cases set_alpha is called with a
> number as the argument. However, the example axes_zoom_effect.py, which was
> recently added to examples/pylab_examples, has these lines:
>
> prop_patches["alpha"]="0.2"
>
> which causes a call to gc.set_alpha of the form gc.set_alpha("0.2"). Backends
> that do not allow strings choke on that.
>
> Whereas in general it may perhaps be useful to allow such strings, it adds
> complexity to the code, and I don't see a good use case for it.
>
> --Michiel.
>
>
>
>
> --
> ___
> Matplotlib-devel mailing list
> Matplotlib-devel@lists.sourceforge.net
> 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] basemap not working with GEOS 3.1
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=1200,height=800, \ 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basemap not working with GEOS 3.1
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=1200,height=800, \ > 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] basemap not working with GEOS 3.1
On Mon, Jul 27, 2009 at 8:14 PM, Jeff Whitaker 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=1200,height=800, \ >> 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
