matplotlib-devel Mailing List for matplotlib

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

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
:)

On Wed, Feb 17, 2010 at 10:17 PM, John Hunter <jd...@gm...> 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

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
>>>>> tmerc Transverse Mercator
>>>>> nplaea North-Polar Lambert Azimuthal
>>>>> gall Gall Stereographic Cylindrical
>>>>> mill Miller Cylindrical
>>>>> merc Mercator
>>>>> stere Stereographic
>>>>> npstere North-Polar Stereographic
>>>>> geos Geostationary
>>>>> vandg van 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
>>>>> omerc Oblique Mercator
>>>>> aea Albers Equal Area
>>>>> spaeqd South-Polar Azimuthal Equidistant
>>>>> ortho Orthographic
>>>>> cass Cassini-Soldner
>>>>> splaea South-Polar Lambert Azimuthal
>>>>> robin Robinson
>>>>>
>>>>> 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/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

On Thu, Feb 18, 2010 at 11:05 AM, Christopher Barker
<Chr...@no...> 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

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
Chr...@no...

On Wed, Feb 17, 2010 at 10:50 PM, Fernando Perez <fpe...@gm...> 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

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
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
>>>> tmerc Transverse Mercator
>>>> nplaea North-Polar Lambert Azimuthal
>>>> gall Gall Stereographic Cylindrical
>>>> mill Miller Cylindrical
>>>> merc Mercator
>>>> stere Stereographic
>>>> npstere North-Polar Stereographic
>>>> geos Geostationary
>>>> vandg van 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
>>>> omerc Oblique Mercator
>>>> aea Albers Equal Area
>>>> spaeqd South-Polar Azimuthal Equidistant
>>>> ortho Orthographic
>>>> cass Cassini-Soldner
>>>> splaea South-Polar Lambert Azimuthal
>>>> robin Robinson
>>>>
>>>> Phillip 
>>> Philip: I think Andrew meant nsper is in proj4. I'll look into 
>>> adding support for it in Basemap.
>>>
>>> -Jeff
>>>
>> Thanks!
>
>

On Wed, Feb 17, 2010 at 10:17 PM, John Hunter <jd...@gm...> wrote:
> I think the name "figsubplots" or "fig_subplots" is better because you
> are creating Subplot instances. Alternatively, you might want to
> consider simply "subplots" which returns just the list of subplots:
> the figure can always be accessed as an attribute of the Subplot
> instance::
>
> ax1, ax2, ax2, ax4 = subplots(2,2)
> fig = ax1.figure
>
> Not sure that this is better; just a thought.
Mmh, even I didn't know that, so I doubt my students would :)
Idle thought: we've inherited the ugly 1-offset numbering scheme for
subplots from matlab, how about making fig_subplots return
[fig, ax1, ax2, ...]
This would at least make it easier to remember indexing, since
axN == ax[N]
would be true. It would also help with the shareax below, see rest of message...
>> Should it go into pyplot directly, or elsewhere and imported from
>> pyplot to expose it at the top-level? (I'm not overly familiar with
>> the layout of the whole library).
>
> pyplots is the right place for it since it is implicitly creating a
> current figure and the only place where that magic happens is in
> pyplot.
OK.
>> I'm also trying to show my students how *they* can improve their
>> tools; e.g. earlier this week a homework problem I wrote up led me to
>> a useful sympy patch that was quickly upstreamed:
>
> 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 :)
> ax1 = fig.add_subplot(211)
> ax2 = fig.add_subplot(212, sharex=ax1)
[...]
> Perhaps the solution to my sharex conundrum is to support an axes number, eg
>
> ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1)
>
> so all the subplots would have sharex with ax1.
That was what I had in mind, I just hadn't had time to try it. Here
it goes (since I started this while preparing class exercises, it's
now in the class git repo):
http://gfif.udea.edu.co/idf/indefero/www/index.php/p/mscomp-2010/source/tree/master/0217/figsubp.py
Comment away, I'll polish it later for mpl over svn, while waiting for
us to catch up with the XXth century and move over to git :)
There are examples to try it out and see how it works (download link
at the bottom of that page).
Cheers,
f

On Wed, Feb 17, 2010 at 8:29 PM, Fernando Perez <fpe...@gm...> wrote:
> On Wed, Feb 17, 2010 at 7:27 PM, David Warde-Farley <dw...@cs...> wrote:
>>
>> An effusive "yes, yes, good god yes!" from this mpl-devel lurker.
>
> Thanks, that's two good pluses.
>
> Any suggestions on name changes, or other fixes to make? Otherwise,
> once I find a free minute I'll put it in.
I think the name "figsubplots" or "fig_subplots" is better because you
are creating Subplot instances. Alternatively, you might want to
consider simply "subplots" which returns just the list of subplots:
the figure can always be accessed as an attribute of the Subplot
instance::
 ax1, ax2, ax2, ax4 = subplots(2,2)
 fig = ax1.figure
Not sure that this is better; just a thought.
> Should it go into pyplot directly, or elsewhere and imported from
> pyplot to expose it at the top-level? (I'm not overly familiar with
> the layout of the whole library).
pyplots is the right place for it since it is implicitly creating a
current figure and the only place where that magic happens is in
pyplot.
> I'm also trying to show my students how *they* can improve their
> tools; e.g. earlier this week a homework problem I wrote up led me to
> a useful sympy patch that was quickly upstreamed:
This is a worthy goal. One use case I would like to see supported
is the sharex/sharey args::
 ax1 = fig.add_subplot(211)
 ax2 = fig.add_subplot(212, sharex=ax1)
If there is not an easy way to specify the shared axes with "figaxes"
or whatever it is called, I would not use it too often, because my
common case is multiple rows of subplots with a common x-axis.
One thing that will be nicer with the suggested patch is it makes it
easier to change a script where the subplot layout goes from 211 to
311 to 411 (this happens to me all the time as I find I want to plot
more stuff for a give time series). I have to change all the 311,
312, 313 to 411, 412, 413, and with your patch it would be a simple
change in one line from::
 ax1, ax2, ax3 = subplots(3,1)
to::
 ax1, ax2, ax3, ax4 = subplots(4,1)
Perhaps the solution to my sharex conundrum is to support an axes number, eg
 ax1, ax2, ax3, ax4 = subplots(4,1, sharex=1)
so all the subplots would have sharex with ax1.
JDH
JDH

On Wed, Feb 17, 2010 at 7:27 PM, David Warde-Farley <dw...@cs...> wrote:
>
> An effusive "yes, yes, good god yes!" from this mpl-devel lurker.
Thanks, that's two good pluses.
Any suggestions on name changes, or other fixes to make? Otherwise,
once I find a free minute I'll put it in.
Should it go into pyplot directly, or elsewhere and imported from
pyplot to expose it at the top-level? (I'm not overly familiar with
the layout of the whole library).
I'm also trying to show my students how *they* can improve their
tools; e.g. earlier this week a homework problem I wrote up led me to
a useful sympy patch that was quickly upstreamed:
http://git.sympy.org/?p=sympy.git;a=commit;h=507c4df6a9edfd5de5ad28535d1f9236db23bf04
and perhaps with this one we can do the same.
I hope that with a few of these examples, at least a few of them will
see the value of making the transition from pure user-mode to more
involved users/contributors (for context, this is a group of
scientists in Colombia with good computational skills but no tradition
of open source contributions; I'm hoping to help a little on this
front).
Cheers,
f

On 17-Feb-10, at 6:52 PM, Fernando Perez wrote:
> Howdy,
>
> in trying to teach a more structured use of mpl, I keep getting
> annoyed by the whole figure(), add_subplot(), grab axes dance. I've
> also seen students get confused by it. Does something along these
> lines sound useful to have in the core (see attached)?
An effusive "yes, yes, good god yes!" from this mpl-devel lurker.
David

Fernando Perez wrote:
> in trying to teach a more structured use of mpl,
good for you!
I always felt that to efficiently use the OO interface, there needed to 
be some more utility functions like this:
> In [37]: figaxes()
> Out[37]:
> (<matplotlib.figure.Figure object at 0xa24b4cc>,
> [<matplotlib.axes.AxesSubplot object at 0x9e74a4c>])
> 
> In [38]: figaxes((2,1))
> Out[38]:
> (<matplotlib.figure.Figure object at 0xa359fcc>,
> [<matplotlib.axes.AxesSubplot object at 0xa47c66c>,
> <matplotlib.axes.AxesSubplot object at 0xa4a5c8c>])
> 
> In [39]: figaxes((2,2),dict(polar=True))
> Out[39]:
> (<matplotlib.figure.Figure object at 0xa6e340c>,
> [<matplotlib.axes.PolarAxesSubplot object at 0xa6fd5ac>,
> <matplotlib.axes.PolarAxesSubplot object at 0xa8b73cc>,
> <matplotlib.axes.PolarAxesSubplot object at 0xa8dd54c>,
> <matplotlib.axes.PolarAxesSubplot object at 0xa9686cc>])
I like it!
-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
Chr...@no...