matplotlib-devel Mailing List for matplotlib (Page 2)

On Thu, Feb 18, 2010 at 11:50 PM, Fernando Perez <fpe...@gm...> wrote:
> 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.
>

After quickly going through the mpl source (and in my experience), I
think it is quite safe to assume that there is no master-slave
relation among the shared axes.


> One more, related question: is it possible/reasonable to share *both*
> x and y axes?

Yes, it is possible as I often do.

>
> 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!

I, personally, am more interested in implementing some form of a
general interface (base class) for a set of axes, although I have no
immediate plan. If I have a chance to work on this, I will try to
adjust those to work with well your code.

Regards,

-JJ


>
> Cheers,
>
> f
>

Dear all,

The draw_path method in backend_cairo.py starts with a check for the number of vertices in the path, and raises an error if the path contains more than 18980 vertices:

     def draw_path(self, gc, path, transform, rgbFace=None):
         if len(path.vertices) > 18980:
             raise ValueError("The Cairo backend can not draw paths longer than 18980 points.")

This was needed in the past when cairo version 1.4.10 / pycairo version 1.4.0 would segfault:

http://sourceforge.net/mailarchive/message.php?msg_name=487E2E78.1050501%40stsci.edu

However, we're now at cairo, pycairo version 1.8.8, and I haven't seen any segfaults after removing this check.

Does anybody object if I remove this check from the code?

--Michiel.



      

Howdy

On Thu, Feb 18, 2010 at 1:19 PM, Jae-Joon Lee <lee...@gm...> 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

On Thu, Feb 18, 2010 at 8:02 AM, John Hunter <jd...@gm...> 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

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...

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

In use, below.  You'd normally capture f, a = figaxes(...) to get the
figure and axes list, but I leave it off here for display purposes:

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


Feedback welcome.

Cheers,

f

On Sat, Feb 13, 2010 at 2:23 PM, T J <tj...@gm...> wrote:
> Subclasses of Axes, such as PolarAxes, inherit many functions which
> make implicit assumptions of rectilinear coordinates.  From a design
> perspective, it seems like most of these functions should not belong
> to the parent class, and that, perhaps, there should exist a
> RectilinearAxes(Axes) class.  Essentially, Axes should contain only
> the methods that are generic enough for every type of axis.  If I were
> to create my own subclass of Axes, I'll either have to tell people to
> not use some of the methods or I'll have to re-implement them all
> (which is definitely not going to happen quickly).
>
> Does this refactoring seem reasonable?

In general, I think this is reasonable thing to do.
However, I'm afraid that this refactoring will involve significant
efforts as the current Axes implementation implicitly assumes
rectlinear coordinates in so many places.
So, I'm not sure if any of the developers is willing to dive in, but
any contribution will be welcomed.

Regards,

-JJ


>
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tue, Feb 16, 2010 at 3:51 AM, Philipp Bender <li...@ro...> wrote:
> Hi,
>
> because Wayne Watson complained in -users repeatedly about spelling errors
> without fixing or really pointing us to them I tried to find some in the
> chapter he mentioned and fixed them. Because I am not a native speaker I hope
> I did not "correct" already correct things.
>
> I attached the diff file.
>
> Please watch it _only_ if you have the time left, it's *really* no big thing.

Thanks Phillip for taking the time to convert this doc bug report from
the users list into a proper patch.  Many of the
usages of axes that Wayne flagged as incorrect in his original report
are actually correct, so some of the patch is not correct but I
understand you were just converting his report into a usable patch.
But there were a couple of fixes in the patch that were worth applying
so I made these in svn HEAD.

> PS: Sphinx is great, good decision!

Yes, it's been great.  We've developed a number of extensions, notably
the ipython and plot directives, that make writing documentation very
natural and easy, and overall I've been very happy with sphinx.

Well, there is something basic now at

    http://github.com/nicki/matplotlib2tikz

It can handle lines plots, images, and color bars; adding more stuff
should not be hard, and in case a few people are interested and
willing to contribute, the script will progress rather quickly I
reckon.

I myself am just picking up Python, so a quick look of the one or the
other pro would certainly be appreciated.

Cheers,
Nico



On Wed, Jan 13, 2010 at 2:24 PM, Michael Droettboom <md...@st...> wrote:
> Andrew Straw wrote:
>>
>> Nico Schlömer wrote:
>>
>>>
>>> Hey, and is there any sort of matplotlib market place where I could
>>> put the file for general bashing/downloading once it can do more than
>>> a sin-plot?
>>>
>>
>> Well, github is my suggestion. If it's a patchset of the MPL source, then
>> fork the MPL repository at http://github.com/astraw/matplotlib . If it's a
>> standalone thing, just create a new project. Github makes this kind of
>> sharing easy at all levels from casual one-off events to close
>> collaboration.
>>
>
> We can also link to it from the matplotlib website once you have a location
> established, for example from here:
>
>  http://matplotlib.sourceforge.net/users/toolkits.html
>
> Mike
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

Hi,

because Wayne Watson complained in -users repeatedly about spelling errors 
without fixing or really pointing us to them I tried to find some in the 
chapter he mentioned and fixed them. Because I am not a native speaker I hope 
I did not "correct" already correct things.

I attached the diff file.

Please watch it _only_ if you have the time left, it's *really* no big thing.

Cheers
Philipp Bender

PS: Sphinx is great, good decision!

Subclasses of Axes, such as PolarAxes, inherit many functions which
make implicit assumptions of rectilinear coordinates.  From a design
perspective, it seems like most of these functions should not belong
to the parent class, and that, perhaps, there should exist a
RectilinearAxes(Axes) class.  Essentially, Axes should contain only
the methods that are generic enough for every type of axis.  If I were
to create my own subclass of Axes, I'll either have to tell people to
not use some of the methods or I'll have to re-implement them all
(which is definitely not going to happen quickly).

Does this refactoring seem reasonable?

Andrew,

jpPlot looks very promising.  I will definitely try to add that into my
code.     

Thanks, 
Brian

Andrew Straw wrote:
> 
> Brian32 wrote:
>> Hello,
>>
>> I am currently displaying plots on a web page using matplotlib by
>> creating
>> .png files.  I would like have the ability for people to have access to
>> the
>> interactive plot feature (Zoom,Save) when they look at the plots on the
>> web
>> page.  I do not care if the plot is a pop up or if is directly on the web
>> page.  At this point I just want the interactive feature available.  I am
>> assuming that the end user that clicks on a web link will already have
>> python/matplotlib installed.  Does anyone know if this is even possible? 
>> If
>> it is I would love to see an example of this.  
>>
>> Thanks in advance,
>> Brian 
>>   
> I think you might be interesting in something like a javascript charting
> library. This webpage lists some interesting options:
> http://www.alsonkemp.com/tools/highcharts-javascript-charting-library/
> 
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 

-- 
View this message in context: http://old.nabble.com/Display-Interactive-plots-on-a-web-page--tp27550397p27566906.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Nadia Dencheva wrote:
> Hi MPL developers,
>
> I use an older matplotlib version but this code is the same in SVN, so I thought
> I'll mention it.
>
> ImportError: numpy 1.1 or later is required; you have 2.0.0.dev8107
Thanks Nadia. Fixed in svn r8128.

-Andrew