Re: [Matplotlib-users] subplot

[Jae-Joon L. <lee...@gm...>]

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
>