I love Matplotlib.
That said, I find the indexing subplots to be an annoyance,
because it uses MATLAB conventions rather than Python
conventions for indexing. I think moving this convention
into the OO API was a mistake.
Since Matplotlib is not yet 1.0,
I am suggesting that this be "fixed".
I understand this will cause some pain.
If it cannot be fixed due to code breakage,
how about an "origin" keyword, that can be 0 or 1?
Cheers,
Alan Isaac
I feel your pain. However, I’m not sure if I like the idea of changing the API or not, but if you’re suggesting changing this:
subplot(2,2,1)
to:
subplot(2, 2, 0, origin=0)
I’m -1 on it. IMO, the solution is worse than the original problem.
Ryan
On Fri, May 15, 2009 at 12:41 PM, Alan G Isaac <aisaac@…310…> wrote:
I love Matplotlib.
That said, I find the indexing subplots to be an annoyance,
because it uses MATLAB conventions rather than Python
conventions for indexing. I think moving this convention
into the OO API was a mistake.
Since Matplotlib is not yet 1.0,
I am suggesting that this be “fixed”.
I understand this will cause some pain.
If it cannot be fixed due to code breakage,
how about an “origin” keyword, that can be 0 or 1?
–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States
I'm less suggesting any particular solution
than suggesting exploring for a solution.
For example, maybe pylab.subplot could use
the current convention, but pyplot.subplot
would behave as expected. Also uncomfortable...
OK, here's another idea. Duplicate the
functionality, leaving subplot as a "convenience"
function for the Matlab crowd. The new function
could be called subplot2grid, and it would take a
shape (2-tuple) and a location (2-tuple).
E.g., ax = fig.subplot2grid(shape=(5,1), loc=(0,3)).
Just exploring ...
Cheers,
Alan Isaac
On 5/15/2009 1:57 PM Ryan May apparently wrote:
I'm not sure if I like the idea of changing the API or not, but if you're suggesting
Exploring in this area is definitely a good thing. I kind of like this proposal and along those lines, I would love to be able to easily create a subplot that occupies 2/3 of a figure in each direction, surrounded by a bunch of smaller panels that each occupy 1/3. I know Jae-Joon has committed a bunch of work on what I’ll call “axes tricks”, but I haven’t had a chance to see if it facilitates this.
Ryan
On Fri, May 15, 2009 at 1:48 PM, Alan G Isaac <alan.isaac@…2015…87…> wrote:
On 5/15/2009 1:57 PM Ryan May apparently wrote:
I’m not sure if I like the idea of changing
the API or not, but if you’re suggesting
I’m less suggesting any particular solution
than suggesting exploring for a solution.
For example, maybe pylab.subplot could use
the current convention, but pyplot.subplot
would behave as expected. Also uncomfortable…
OK, here’s another idea. Duplicate the
functionality, leaving subplot as a “convenience”
function for the Matlab crowd. The new function
could be called subplot2grid, and it would take a
shape (2-tuple) and a location (2-tuple).
E.g., ax = fig.subplot2grid(shape=(5,1), loc=(0,3)).
Just exploring …
–
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States
It would be good if we can (optionally) specify a location as ranges
in each direction so that the axes can occupy not just a single cell
of the grid but can spans multiple cells, similar to what Ryan has
suggested. For example, shape(3,3), loc=((0,2), (0,2)) may create a
subplot what Ryan has suggested.
-JJ
On Fri, May 15, 2009 at 2:48 PM, Alan G Isaac <alan.isaac@...287...> wrote:
E.g., ax = fig.subplot2grid(shape=(5,1), loc=(0,3)).
Exploring in this area is definitely a good thing. I kind of like this
proposal and along those lines, I would love to be able to *easily* create a
subplot that occupies 2/3 of a figure in each direction, surrounded by a
bunch of smaller panels that each occupy 1/3. I know Jae-Joon has committed
a bunch of work on what I'll call "axes tricks", but I haven't had a chance
to see if it facilitates this.Ryan
It may be doable, depending on what you exactly want.
For example
http://dl.getdropbox.com/u/178748/AxesGrid/htdocs/users/overview.html#rgb-axes
But my emphasis was on displaying images, and may not be suitable for
general axes.
-JJ
FYI, several weeks ago I updated the official site-docs after you
contributes the axes grid toolkit and docs:
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#rgb-axes
Which only increases the pressure on us to get the 98 bug fix release
out and then the next trunk release out so that the code keeps up with
the docs...
JDH
On Fri, May 15, 2009 at 4:24 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
It may be doable, depending on what you exactly want.
For examplehttp://dl.getdropbox.com/u/178748/AxesGrid/htdocs/users/overview.html#rgb-axes
But my emphasis was on displaying images, and may not be suitable for
general axes.
Thanks a lot, John.
However, example figures are missing currently. (instead it shows a
message "Exception occurred rendering plot.").
Also, API documentations are not correctly generated also. My quick
guess is that the axes_grid module was not found during the sphinx
run. Can you take a look? The documentation builds fine for me.
Regards,
-JJ
On Fri, May 15, 2009 at 10:10 PM, John Hunter <jdh2358@...287...> wrote:
FYI, several weeks ago I updated the official site-docs after you
contributes the axes grid toolkit and docs:http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#rgb-axes
Oops, sorry about that. Looks like I have it fixed now.
JDH
On Sat, May 16, 2009 at 10:58 PM, Jae-Joon Lee <lee.j.joon@...287...> wrote:
http://matplotlib.sourceforge.net/mpl_toolkits/axes_grid/users/overview.html#rgb-axes
Thanks a lot, John.
However, example figures are missing currently. (instead it shows a
message "Exception occurred rendering plot.").
Also, API documentations are not correctly generated also. My quick
guess is that the axes_grid module was not found during the sphinx
run. Can you take a look? The documentation builds fine for me.
Oops, sorry about that. Looks like I have it fixed now.
JDH
Yes, it looks fine now.
Thanks!
-JJ
Hi all,
I had a few off-list conversation with Alan, and I'm also quite agree
with him for this issue.
Just to rephrase, I think the current subplot interface has (at least)
two issues.
issue 1) the indexing convention is not that of python. The index
starts from 1, instead of 0. (eg "111")
issue 2) It is not easy (actually impossible) to make an axes
spanning multiple cells.
While I think we need to keep the current interface at least for a
while, it would be better if we come up with some pythonic interface
that may eventually replace the current matlab-centric one.
So, how other developers and users think about this?
And here are a few options that has been suggested.
Option 1) use of "origin" keyword.
ex) subplot(2, 2, 0, origin=0)
Ryan is -1 for this and so am I.
It also does not address the issue 2.
Option 2) Introduce a new command
ex1) ax = fig.subplot2grid(shape=(3,3), loc=(0,0), rowspan=2, colspan=2)
Instead of simple subplot(111), we may do something like
ex2) ax = fig.subplot2grid((1,1), 0)
Option 3) introduce a new class for grid specification and modify
subplot to accept this.
One idea I have is to use an array-like interface.
ex1) ax = fig.subplot(grid_spec(3,3)[0:2,0:2])
For subplot(111) equivalent,
ex2) ax = fig.subplot(grid_spec(1,1)[0])
I, personally, want to reuse the convention in my axes_grid toolkit,
where it would be better if this grid specification(?) can be
expressed as a single argument. And I'm +1 for option 3 for this
reason. However, I'm afraid that option 3 is not expressive enough.
Of course, we should explore other solutions and any suggestions will
be welcomed.
So, how others think?
Regards,
-JJ
On Fri, May 15, 2009 at 1:41 PM, Alan G Isaac <aisaac@...310...> wrote:
I love Matplotlib.
That said, I find the indexing subplots to be an annoyance,
because it uses MATLAB conventions rather than Python
conventions for indexing. I think moving this convention
into the OO API was a mistake.Since Matplotlib is not yet 1.0,
I am suggesting that this be "fixed".
I understand this will cause some pain.If it cannot be fixed due to code breakage,
how about an "origin" keyword, that can be 0 or 1?Cheers,
Alan Isaac------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
matplotlib-users List Signup and Options