Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:50 PM, Fernando Perez wrote: >> This is a worthy goal. One use case I would like to see supported >> is the sharex/sharey args:: > Sheesh, some people really want everything :) Yes, you should know better by now than to propose a minor enhancement Another thought about the interface. How about *just* returning the figure instance, and let the users simply index into the axes list. Then they can have their 0 based indexing because it is a python list:: fig = fig_subplot((2,1), sharex=1) fig.axes[0].plot(...) fig.axes[1].scatter(...) mpl is creating this axes list anyway I'm also fine with your implementation -- just a suggestion. One other thing: I don't think a tuple is best for the axes dimensionality. We always require two and exactly two shape arguments (numrows, numcols) so we don't need the flexibility of the tuple in the way that numpy.zeros does. And it is easier to type:: fig_subplot(2, 1, sharex=1) than:: fig_subplot((2,1), sharex=1) As the world master of keystroke efficiency, I would think you would appreciate the savings! But again, if you prefer the tuple, I don't have a problem with it. It does have the advantage of visually suggesting a single shape argument. JDH -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
John Hunter wrote: > One other thing: I don't think a tuple is best for the axes > dimensionality. We always require two and exactly two shape arguments > (numrows, numcols) so we don't need the flexibility of the tuple in > the way that numpy.zeros does. And it is easier to type:: > > fig_subplot(2, 1, sharex=1) > > than:: > > fig_subplot((2,1), sharex=1) would we want to support: fig_subplot( (2,) ) If so, then a tuple has a real advantage. If not, then it doesn't make much difference, though I still prefer the tuple, as I can imagine that I might define that somewhere else, and it's handy to have it as a single object. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Feb 18, 2010 at 11:05 AM, Christopher Barker wrote: > John Hunter wrote: > fig_subplot( (2,) ) > > If so, then a tuple has a real advantage. If not, then it doesn't make > much difference, though I still prefer the tuple, as I can imagine that > I might define that somewhere else, and it's handy to have it as a > single object. fig_subplot( (2,) ) is still more characters than fig_subplot( 2,1), and more shifted characters which can be harder to type, but since they are sequential with the function call parentheses in this case it is probably not a problem. I'm not convinced by the "single object" argument. To do something useful with the axes that are generated, you probably will need in your code to know how many rows and columns you have, so at some point you['ll need to define numrows and numcols as variables anyhow. Perhaps the following is the best: def fig_subplot(numrows=1, numcols=1, ...blah): Since the most common use case is 1,1 followed by 2,1, one can write fig_subplot() # for 1,1 fig_subplot(2) # for 2,1 fig_subplot(numcols=2) # for 1,2 JDH But it's not an important difference -- Fernando should just go with what feels most natural to him -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] missing projections
Phillip M. Feldman wrote: > This sounds great. Thanks! > > So far I haven't figured out how to use it. I downloaded the > matplotlib SVN and installed it, but was not able to find > "nsper_demo.py". > > Phillip Phillip: Basemap is a separate toolkit, you won't get it from the matplotlib svn trunk. Instead of svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/matplotlib matplotlib do svn co https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/trunk/toolkits/basemap basemap -Jeff > > Jeff Whitaker wrote: >> Phillip M. Feldman wrote: >>> Jeff Whitaker wrote: Phillip M. Feldman wrote: > Andrew Straw wrote: >> Jeff Whitaker wrote: >> >>> Dr. Phillip M. Feldman wrote: >>> Basemap offers many projections, but is missing two of the most useful ones: - For satellite applications, it would be helpful to have a "camera" projection, i.e., a projection that shows the Earth as viewed from a specified point in space. This would be a generalization of the current geostationary projection. >>> Philip: Don't think the proj4 lib supports this. >>> >> I think it's already in there -- see nsper, for near sided >> perspective. >> >> -Andrew >> >> >> Philip: I've added the near-sided perspective projection to basemap >> svn - see the nsper_demo.py example. It only works if the earth is >> assumed to be a perfect sphere (no ellipsoids allowed). >> >> -Jeff >> > Hello Andrew- > > It does sound as thought nsper is exactly what I need, but when I > try to use it, I get the following error message: > > ValueError: 'nsper' is an unsupported projection. > The supported projections are: > > aeqd Azimuthal Equidistant > poly Polyconic > gnom Gnomonic > moll Mollweide > tmercTransverse Mercator > nplaea North-Polar Lambert Azimuthal > gall Gall Stereographic Cylindrical > mill Miller Cylindrical > merc Mercator > stereStereographic > npstere North-Polar Stereographic > geos Geostationary > vandgvan der Grinten > laea Lambert Azimuthal Equal Area > mbtfpq McBryde-Thomas Flat-Polar Quartic > sinu Sinusoidal > spstere South-Polar Stereographic > lcc Lambert Conformal > npaeqd North-Polar Azimuthal Equidistant > eqdc Equidistant Conic > cyl Cylindrical Equidistant > omercOblique Mercator > aea Albers Equal Area > spaeqd South-Polar Azimuthal Equidistant > orthoOrthographic > cass Cassini-Soldner > splaea South-Polar Lambert Azimuthal > robinRobinson > > Phillip Philip: I think Andrew meant nsper is in proj4. I'll look into adding support for it in Basemap. -Jeff >>> Thanks! >> >> > -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX: (303)497-6449 NOAA/OAR/PSD R/PSD1Email : jeffrey.s.whita...@noaa.gov 325 BroadwayOffice : Skaggs Research Cntr 1D-113 Boulder, CO, USA 80303-3328 Web: http://tinyurl.com/5telg -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:17 PM, John Hunter wrote: > Perhaps the solution to my sharex conundrum is to support an axes number, eg > > ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1) > I thought there is no master and slave for an axis-sharing? If that's the case, maybe "sharex=True" should be suffice? Also, how about "subplots" returns a some kind of object so that we may define some methods on it. We can define "__iter__" method so that above syntax also works. As an example, mysubplots = subplots(4,1, sharex=True) mysubplots.label_outer() ax1, ax2, ax3, ax4 = mysubplots Regards, -JJ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] NumPy version check
Just noticed this when I tried to build (I have numpy from svn): REQUIRED DEPENDENCIES * numpy 1.1 or later is required; you have * 2.0.0.dev8125 :) -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] NumPy version check
On 2010-02-18 16:18 PM, David Warde-Farley wrote: > Just noticed this when I tried to build (I have numpy from svn): > > REQUIRED DEPENDENCIES > * numpy 1.1 or later is required; you have > * 2.0.0.dev8125 > > :) This has been fixed in SVN. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Feb 18, 2010 at 8:02 AM, John Hunter wrote: > Yes, you should know better by now than to propose a minor enhancement And you should know by know common sense has somehow been amputated from my system :) > Another thought about the interface. How about *just* returning the > figure instance, and let the users simply index into the axes list. > Then they can have their 0 based indexing because it is a python > list:: > > fig = fig_subplot((2,1), sharex=1) > fig.axes[0].plot(...) > fig.axes[1].scatter(...) > > mpl is creating this axes list anyway I'm also fine with your > implementation -- just a suggestion. Mmh, doubting: the more compact api is appealing, but in actual use it seems to make for a lot of typing, since the really useful objects for most things are the axes. Given that in python3 we'll have more flexible unpacking: Python 3.1.1 (r311:74480, Sep 18 2009, 19:43:55) [GCC 4.3.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> a = list(range(10)) >>> x, y, *z = a >>> x, y, z (0, 1, [2, 3, 4, 5, 6, 7, 8, 9]) >>> m, *n, p, q = a >>> m, n, p, q (0, [1, 2, 3, 4, 5, 6, 7], 8, 9) makes me lean towards keeping the [fig, ax1, ax2...] notation. But I'm willing to reconsider on further arguments. > One other thing: I don't think a tuple is best for the axes > dimensionality. We always require two and exactly two shape arguments > (numrows, numcols) so we don't need the flexibility of the tuple in > the way that numpy.zeros does. And it is easier to type:: > > fig_subplot(2, 1, sharex=1) > > than:: > > fig_subplot((2,1), sharex=1) > > As the world master of keystroke efficiency, I would think you would > appreciate the savings! But again, if you prefer the tuple, I don't > have a problem with it. It does have the advantage of visually > suggesting a single shape argument. > +1 for the (nr, nc, share...) form. I won't have time to work on this for a couple of days though; keep further feedback coming, I should be back home on Monday and able to finish it (I'm away on a teaching-sprint-within-a-teaching-marathon for a couple of days). If anyone wants to finish it first, run with it., I'm not personally attached to it. Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Howdy On Thu, Feb 18, 2010 at 1:19 PM, Jae-Joon Lee wrote: > > I thought there is no master and slave for an axis-sharing? > If that's the case, maybe "sharex=True" should be suffice? I defer to your wisdom here: I had no clue about this, so I went for the clumsier API. If you are right, it would also make the implementation much simpler, as I had to play some not-totally-obvious gymnastics to alter axis creation order based on this parameter. One more, related question: is it possible/reasonable to share *both* x and y axes? It would be really nice if you were correct. The api could be nicer and the implementation simpler. > Also, how about "subplots" returns a some kind of object so that we > may define some methods on it. We can define "__iter__" method so > that above syntax also works. As an example, > > mysubplots = subplots(4,1, sharex=True) > mysubplots.label_outer() > ax1, ax2, ax3, ax4 = mysubplots Mmh, more than I have time for right now, I'm afraid (I'm really pushing it with these little side-trips already). But if you do have a minute to do it, run with it. I can only commit to finish the basic implementation with the changes discussed above, plus any fixes to share* based on clarifying these points. A fancier object API would be great to have, so by all means go ahead if you have the bandwidth! Cheers, f -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
