Thread: [Matplotlib-users] subplot

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

On Fri, May 15, 2009 at 12:41 PM, Alan G Isaac <ai...@am...> 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?


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

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

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

Cheers,
Alan Isaac

On Fri, May 15, 2009 at 2:48 PM, Alan G Isaac <ala...@gm...> wrote:
> E.g., ax = fig.subplot2grid(shape=(5,1), loc=(0,3)).

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 1:48 PM, Alan G Isaac <ala...@gm...> 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 ...


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

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

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

On Fri, May 15, 2009 at 4:24 PM, Jae-Joon Lee <lee...@gm...> wrote:

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


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 10:10 PM, John Hunter <jd...@gm...> 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

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 Sat, May 16, 2009 at 10:58 PM, Jae-Joon Lee <lee...@gm...> 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

> Oops, sorry about that.  Looks like I have it fixed now.
>
> JDH
>


Yes, it looks fine now.
Thanks!

-JJ

On 5/17/2009 2:44 PM Jae-Joon Lee apparently wrote:
> I meant consistency with Matplotlib itself.

My point is that that is not well defined,
since most of the OO API in Matplotlib is
Python centric, but the subplot definition
is an exception.

So I am suggesting that any new functions
certainly should not propagate this anomaly.

 > I agree and I'm personally for python-centric interface throughout matplotlib.
 > I think what we need is to devise a new python-centric interface
 > (e.g., subplot2grid you suggested) and may try to deprecate subplot
 > eventually.

So, looking forward, keeping that anomaly isolated
will be important, so that changes do not need to
be made in additional locations. (Or so I claim...)

Cheers,
Alan Isaac

On Sun, May 17, 2009 at 5:03 PM, Alan G Isaac <ala...@gm...> wrote:
> So I am suggesting that any new functions
> certainly should not propagate this anomaly.

Understood. And, yes, I guess you're quite right in this regard.
And I'll try to deprecate the current matlab-like interface in future
(at least in my axes_grid toolkit).

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 <ai...@am...> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Hi,

Jae-Joon Lee <lee.j.joon@...> writes:
> I had a few off-list conversation with Alan, and I'm also quite agree
> with him for this issue.
[...]
>  issue 2)  It is not easy (actually impossible) to make an axes
> spanning multiple cells.

Regarding this 2nd issue, I appreciated long ago the flexibility and ease-of-use
offered by super-mongo WINDOW command (e.g.
http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83). Basically, this would be
the same as accepting a tuple as plotNum argument in matplotlib subplot(numRows,
numCols, plotNum) to specify the extent of the composed subplot in terms of
atomic subplots, e.g.

ax1 = subplot(2,2,(1,3))
ax2 = subplot(2,2,2)
ax3 = subplot(2,2,4)

would produce the following layout:

+-------+-------+
|       |  ax2  |
|       |       |
|  ax1  +-------+
|       |  ax3  |
|       |       |
+-------+-------+

or 

ax1 = subplot(3,3,(1,5))
ax2 = subplot(3,3,(7,9))
ax3 = subplot(3,3,(3,6))

for 

+-------+---+
|       |   |
|  ax1  |ax3|
|       |   |
+-------+---+
|    ax2    |
+-----------+

My current naive implementation is the following:

def add_axes(fig, nrow, ncol, extent, **kwargs):

    pars = fig.subplotpars
    figW = pars.right-pars.left                 # Fig size
    figH = pars.top-pars.bottom
    subW = figW / (ncol + pars.wspace*(ncol-1)) # Sub-axes size
    subH = figH / (nrow + pars.hspace*(nrow-1))
    sepW = pars.wspace*subW                     # Separations
    sepH = pars.hspace*subH

    axL,axR,axB,axT = 1,0,1,0
    for num in extent:
        assert 0<num<=nrow*ncol
        irow, icol =  divmod(num-1, ncol)
        subL = pars.left + icol*(subW + sepW)
        subB = pars.top - (irow+1)*subH - irow*sepH
        axL = min(axL,subL)
        axR = max(axR,subL+subW)
        axB = min(axB,subB)
        axT = max(axT,subB+subH)
    axW = axR-axL
    axH = axT-axB

    return fig.add_axes([axL,axB,axW,axH], **kwargs)

fig = figure()
ax1 = add_axes(fig,3,3,(1,5))
ax2 = add_axes(fig,3,3,(7,9))
ax3 = add_axes(fig,3,3,(3,6))
ax1.plot(randn(10),'b.')
ax2.plot(randn(10),'r.')
ax3.plot(randn(10),'g.')
draw()

Cheers.

On 5/18/2009 4:27 PM Yannick Copin apparently wrote:
> super-mongo WINDOW command (e.g.
> http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83)


The functionality is good,
but the syntax is awful.

Using a location along with
a rowspan and colspan is a
very established convention.
(E.g., consider the tkinter
grid manager.)  It is
completely explicit and
simple, even when changing
the extent in only a single
direction.

subplot2grid(loc=(0,0), rowspan=2, colspan=3)

would confuse nobody (or so I claim).

Alan

Hi guys,

+1 for rowspan and colspan. Much cleaner I would say.

Chaitanya

On Mon, May 18, 2009 at 11:17 PM, Alan G Isaac <ala...@gm...> wrote:
> On 5/18/2009 4:27 PM Yannick Copin apparently wrote:
>> super-mongo WINDOW command (e.g.
>> http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83)
>
>
> The functionality is good,
> but the syntax is awful.
>
> Using a location along with
> a rowspan and colspan is a
> very established convention.
> (E.g., consider the tkinter
> grid manager.)  It is
> completely explicit and
> simple, even when changing
> the extent in only a single
> direction.
>
> subplot2grid(loc=(0,0), rowspan=2, colspan=3)
>
> would confuse nobody (or so I claim).
>
> Alan
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 5/18/2009 5:17 PM Alan G Isaac apparently wrote:
> subplot2grid(loc=(0,0), rowspan=2, colspan=3)
> would confuse nobody (or so I claim).

That should have been:
subplot2grid(shape=(3,3), loc=(0,0), rowspan=2, colspan=3)

Alan Isaac

Alan G Isaac <alan.isaac@...> writes:
> On 5/18/2009 4:27 PM Yannick Copin apparently wrote:
> > super-mongo WINDOW command (e.g.
> > http://www.astro.princeton.edu/~rhl/sm/sm.html#SYN83)
> 
> The functionality is good,
> but the syntax is awful.

It might not be crystal clear indeed at 1st glance, but once you get used 
to it (as I got used to sm-WINDOW command), it is fairly trivial to 
pre-visualize. And IMHO it would have the advantage of conciseness while 
an easy extension to subplot.

> subplot2grid(loc=(0,0), rowspan=2, colspan=3)
> 
> would confuse nobody (or so I claim).

Most probably... but me: I did not catch what subplot2grid(loc=(0,0), 
rowspan=2, colspan=3) should actually do. What would be the syntax for 
the following layouts?

+-----+-----+
|     | ax2 |
| ax1 +-----+
|     | ax3 |
+-----+-----+

+-------+---+
|       |   |
|  ax1  |ax3|
|       |   |
+-------+---+
|    ax2    |
+-----------+

Cheers.

On 5/18/2009 6:25 PM Yannick Copin apparently wrote:
> rowspan=2, colspan=3) should actually do. What would be the syntax for 
> the following layouts?
>
> +-----+-----+
> |     | ax2 |
> | ax1 +-----+
> |     | ax3 |
> +-----+-----+

subplot2grid(shape=(2,2), loc=(0,0), rowspan=2)
subplot2grid(shape=(2,2), loc=(0,1))
subplot2grid(shape=(2,2), loc=(1,1))


> +-------+---+
> |       |   |
> |  ax1  |ax3|
> |       |   |
> +-------+---+
> |    ax2    |
> +-----------+


subplot2grid(shape=(3,3), loc=(0,0), rowspan=2, colspan=2)
subplot2grid(shape=(3,3), loc=(0,2), rowspan=2)
subplot2grid(shape=(3,3), loc=(2,0), colspan=3)

Again, consider the tkinter grid manager.

hth,
Alan Isaac

On 5/18/2009 6:25 PM Yannick Copin apparently wrote:
> rowspan=2, colspan=3) should actually do. What would be the syntax for 
> the following layouts?
> 
> +-----+-----+
> |     | ax2 |
> | ax1 +-----+
> |     | ax3 |
> +-----+-----+

subplot2grid(shape=(2,2), loc=(0,0), rowspan=2)
subplot2grid(shape=(2,2), loc=(0,1))
subplot2grid(shape=(2,2), loc=(1,1))


> +-------+---+
> |       |   |
> |  ax1  |ax3|
> |       |   |
> +-------+---+
> |    ax2    |
> +-----------+


subplot2grid(shape=(3,3), loc=(0,0), rowspan=2, colspan=2)
subplot2grid(shape=(3,3), loc=(0,2), rowspan=2)
subplot2grid(shape=(3,3), loc=(2,0), colspan=3)

Again, consider the tkinter grid manager.

hth,
Alan Isaac

Alan G Isaac wrote:
> Using a location along with
> a rowspan and colspan is a
> very established convention.

This is used by the wxPython GridBagSizer as well.

Speaking of which, I recall a good while back someone was working on a 
axes layout system modeled after wx Sizers -- anyone know what happened 
to that?

-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 Tue, May 19, 2009 at 12:51 PM, Christopher Barker
<Chr...@no...> wrote:
> Alan G Isaac wrote:
>> Using a location along with
>> a rowspan and colspan is a
>> very established convention.
>
> This is used by the wxPython GridBagSizer as well.
>
> Speaking of which, I recall a good while back someone was working on a
> axes layout system modeled after wx Sizers -- anyone know what happened
> to that?
>

I guess you're referring to mplsizer by Andrew Straw?

http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/toolkits/mplsizer/

-JJ


> -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...
>
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I think there is no functionality difference between subplot2grid and
SM Window. And the syntax of the subplot2grid seems much more cleaner,
especially when you have large number of cells. So, I'm +1 for
subplot2grid in this regard.

One thing I like about my option 3 is that it can have some benefit
from the array indexing. For example,


>
>> +-------+---+
>> |       |   |
>> |  ax1  |ax3|
>> |       |   |
>> +-------+---+
>> |    ax2    |
>> +-----------+
>


ax2 = subplot(grid_spec(3,3)[2,:])

Any suggestions?

-JJ

On Tue, May 19, 2009 at 12:00 PM, Jae-Joon Lee <lee...@gm...> wrote:

> I think there is no functionality difference between subplot2grid and
> SM Window. And the syntax of the subplot2grid seems much more cleaner,
> especially when you have large number of cells. So, I'm +1 for
> subplot2grid in this regard.
>
> One thing I like about my option 3 is that it can have some benefit
> from the array indexing. For example,
>
>
> >
> >> +-------+---+
> >> |       |   |
> >> |  ax1  |ax3|
> >> |       |   |
> >> +-------+---+
> >> |    ax2    |
> >> +-----------+
> >
>
>
> ax2 = subplot(grid_spec(3,3)[2,:])
>
> Any suggestions?


I'll admit that I wasn't too sure about this when you first introduced it,
but it's growing on me.  I could foresee this usage:

#Make grid
ax_grid = grid_spec(3,3)

ax1 = subplot(ax_grid[:2, :2])
#do plot 1

ax2 = subplot(ax_grid[2, :])
#do plot 2

ax3 = subplot(ax_grid[:2, 2])
#do plot3

What I like about this is that it uses fewer keyword arguments and doesn't
add another function with overlapping functionality to the API, but adds
functionality to the function that already handles subplots.  I also like
that it makes use of a syntax (slicing) that pretty much everyone has to be
familiar with.  I could also see that the grid_spec could cache some
calculations (slight performance benefit) as well as (maybe?) handle what
happens when overlapping axes are requested from the grid.

My 0.02.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States

Jae-Joon Lee wrote:
> I guess you're referring to mplsizer by Andrew Straw?
> 
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/toolkits/mplsizer/

yup -- that's it. It looks like it hasn't been touched in a year or so. 
Maybe this is a good time to revive it? I think it's a great idea.

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