Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sun, Mar 21, 2010 at 8:10 PM, Fernando Perez fperez@gmail.com wrote: Mmh, back to this one: I do think it would be something useful to have somewhere, because typing draw() after *every* operation when working interactively does get tiresome, it seems to me... If we encourage calling subplots() for new teaching, then we do want it to be as pleasant as pyplot to use interactively, I think... I think the first issue that needs to be addressed is whether we want to encourage OO api in the interactive mode (I mean, when a user expect the figure gets updated as soon as a command is executed). Using *subplots* does not necessarily mean that we need to use OO api, since we now have *sca* in the pyplot namespace. So. how other developers think? Are we going to encourage OO api in the interactive mode? Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Fernando Perez skrev 2010-03-22 01:10: On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Leelee.j.j...@gmail.com wrote: On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perezfperez@gmail.com wrote: I wonder if it's possible to put things like a draw_if_interactive() call at the end of the OO methods... I realize that pyplot was the only one meant to do that, but if we are to encourage using the OO api more, then it's going to have to be as pleasant to use as pyplot... I don't know the codebase well enough to mess with this right now, so I hope someone who's more versed in that part of the code can make a fix for this whose impact isn't too severe on the runtime of OO code. I'm not very inclined to this but I'll wait to hear what others think. I use oo api in the interactive mode but I still prefer to call draw() explicitly. Of course, we can make it optional. Mmh, back to this one: I do think it would be something useful to have somewhere, because typing draw() after *every* operation when working interactively does get tiresome, it seems to me... If we encourage calling subplots() for new teaching, then we do want it to be as pleasant as pyplot to use interactively, I think... Would it be possible to put the draw in the ipython_prompt hook. That way it is always called after you have done something. /Jörgen -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Mon, Mar 22, 2010 at 11:50 AM, Jörgen Stenarson jorgen.stenar...@bostream.nu wrote: Would it be possible to put the draw in the ipython_prompt hook. That way it is always called after you have done something. I like this approach better, because one problem with doing it in the mpl Artist layer is that one artist setter may call another, and trigger a series of calls to draw for what is only a single draw at the interactive prompt. ipython knows when an interactive call is made, and can issue a draw. The trick will be to manage something like a needdraw flag for all mpl figures, which is set when any property contained in that fiugure changed and flushed when any call to draw is made. If we maintain this flag on all mpl setters and flush it after all mpl draws, the ipython prompt hook could check the flag and draw if needed when interactive is True. Not sure it is worth the effort, since like JJ I tend to mostly use the pyplot functions when working from the interactive shell and don't mind calling draw when using the API. I don't think API usage should be encouraged for the interactive prompt -- but I don't think it should be discouraged either -- it's just that in practice most experienced users use the state machine in this case because it is less typing and we needn't be pedantic, even when teaching wink. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu wrote: Done in svn 8205. Thanks! Or, how about we make axes an context manager. This would require dropping support for Python 2.4. I don't think making the Axes a context manager means dropping python 2.4 support (note that I'm not saying we use with statement in the mpl source). Everything should work fine in python 2.4 (please correct me if I'm wrong). It just gives a user a choice. If a user runs his/her script with python 2.5 and higher, he/she has an option to use an axes as an context manager. Of course, if he/she want his/her own code supported in python 2.4, he/she should not use with statement. Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu wrote: Or, how about we make axes an context manager. This would require dropping support for Python 2.4. I don't think making the Axes a context manager means dropping python 2.4 support (note that I'm not saying we use with statement in the mpl source). Everything should work fine in python 2.4 (please correct me if I'm wrong). It just gives a user a choice. If a user runs his/her script with python 2.5 and higher, he/she has an option to use an axes as an context manager. Of course, if he/she want his/her own code supported in python 2.4, he/she should not use with statement. I see what you're saying. While the use of the language syntax is restricted to 2.5 and above, we could add the needed methods to the Axes object, which would just be ignored by python 2.5. That's not a bad idea. I'm +1 on the idea. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Ryan May wrote: On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu wrote: Or, how about we make axes an context manager. This would require dropping support for Python 2.4. I don't think making the Axes a context manager means dropping python 2.4 support (note that I'm not saying we use with statement in the mpl source). Everything should work fine in python 2.4 (please correct me if I'm wrong). It just gives a user a choice. If a user runs his/her script with python 2.5 and higher, he/she has an option to use an axes as an context manager. Of course, if he/she want his/her own code supported in python 2.4, he/she should not use with statement. I see what you're saying. While the use of the language syntax is restricted to 2.5 and above, we could add the needed methods to the Axes object, which would just be ignored by python 2.5. That's not a bad idea. I'm +1 on the idea. Is the added complexity, scrambling pylab into the OO layer, and need for explanation, really worth the gain? As far as I can see, it merely adds one more way to do something--and not a particularly recommended way. It is no more concise than using sca(). It may be slightly more readable because of the indentation, but that is the only advantage I see. Eric Ryan -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu wrote: By the way, given that we now have suplots in the pyplot namespace, can we have sca also? Done in svn 8205. Eric, A minor question. I wonder whether an explicit for-loop inside pyplot.sca is necessary? Here is a slight variation w/o a for-loop (well, the for-loop is implicitly done with the in operator I guess) that seems to work for me, but I may be missing something. managers = _pylab_helpers.Gcf.get_all_fig_managers() if ax.figure.canvas.manager in managers and \ ax in ax.figure.axes: _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager) ax.figure.sca(ax) return raise ValueError(Axes instance argument was not found in a figure.) Regards, -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Jae-Joon Lee wrote: On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing efir...@hawaii.edu mailto:efir...@hawaii.edu wrote: By the way, given that we now have suplots in the pyplot namespace, can we have sca also? Done in svn 8205. Eric, A minor question. I wonder whether an explicit for-loop inside pyplot.sca is necessary? Here is a slight variation w/o a for-loop (well, the for-loop is implicitly done with the in operator I guess) that seems to work for me, but I may be missing something. managers = _pylab_helpers.Gcf.get_all_fig_managers() if ax.figure.canvas.manager in managers and \ ax in ax.figure.axes: _pylab_helpers.Gcf.set_active(ax.figure.canvas.manager) ax.figure.sca(ax) return raise ValueError(Axes instance argument was not found in a figure.) Regards, -JJ JJ, I think your version would need an additional try/except or conditional, because a Figure doesn't necessarily have a canvas assigned to it, and a canvas doesn't necessarily have a manager. Granted, the problem would arise only under odd circumstances involving a mixture of pyplot and OO styles--and maybe there is actually something that would prevent the problem from arising at all--but I would want to be sure the problem either was handled, or could not arise. So, I think my version ends up being simpler, safer, and easier to understand--at least for me. Eric -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sun, Mar 21, 2010 at 6:07 PM, Eric Firing efir...@hawaii.edu wrote: I think your version would need an additional try/except or conditional, because a Figure doesn't necessarily have a canvas assigned to it, and a canvas doesn't necessarily have a manager. Granted, the problem would arise only under odd circumstances involving a mixture of pyplot and OO styles--and maybe there is actually something that would prevent the problem from arising at all--but I would want to be sure the problem either was handled, or could not arise. So, I think my version ends up being simpler, safer, and easier to understand--at least for me. I see. Thanks! -JJ -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez fperez@gmail.com wrote: I wonder if it's possible to put things like a draw_if_interactive() call at the end of the OO methods... I realize that pyplot was the only one meant to do that, but if we are to encourage using the OO api more, then it's going to have to be as pleasant to use as pyplot... I don't know the codebase well enough to mess with this right now, so I hope someone who's more versed in that part of the code can make a fix for this whose impact isn't too severe on the runtime of OO code. I'm not very inclined to this but I'll wait to hear what others think. I use oo api in the interactive mode but I still prefer to call draw() explicitly. Of course, we can make it optional. Mmh, back to this one: I do think it would be something useful to have somewhere, because typing draw() after *every* operation when working interactively does get tiresome, it seems to me... If we encourage calling subplots() for new teaching, then we do want it to be as pleasant as pyplot to use interactively, I think... Is it technically expensive to put in? Cheers, f -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 6:39 PM, John Hunter jdh2...@gmail.com wrote: I also think the name should be changed, and there should be an entry in the matplotlib.figure.Figure API. One additional suggestion is subarray and matplotlib.pyplot.subarray would be a thin wrapper to matplotlib.figure.Figure.add_subarray. The former would return (fig, axarray) using gcf() to get the current figure, and the latter would simply create the subarray and return it. The would break a bit with the pyplot axes and subplot commands that only return the Axes and Subplot instances (and not the implicit Figure instance created/used) but I can live with that because part of the goal here is to give easy access to axes and figure creation so the user can get in the habit of using the API directly for most things. As for the other name suggestions, I like subplots. Without further feedback, I went with John's vote on 'subplots' and have committed the changes to the API as agreed, now naming it plt.subplots(). I'm sorry but I didn't implement the full Figure.add_subarray() changes you suggested, ran out of time... There is, however, a fly in the ointment: while this new code feels very nice from playing wtih it in scripts like the example just committed: http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/examples/pylab_examples/subplots_demo.py?revision=8202view=markup it is NOT pleasant to use interactively, because the OO api requires explicit draw() calls all the time. I just realized this now using it more, and it's a bummer, because it makes it less likely that one will use this type of code in everyday interactive exploration. I wonder if it's possible to put things like a draw_if_interactive() call at the end of the OO methods... I realize that pyplot was the only one meant to do that, but if we are to encourage using the OO api more, then it's going to have to be as pleasant to use as pyplot... I don't know the codebase well enough to mess with this right now, so I hope someone who's more versed in that part of the code can make a fix for this whose impact isn't too severe on the runtime of OO code. Cheers, f ps - Chris, thanks for the encouragement :) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez fperez@gmail.com wrote:
I wonder if it's possible to put things like a draw_if_interactive()
call at the end of the OO methods... I realize that pyplot was the
only one meant to do that, but if we are to encourage using the OO api
more, then it's going to have to be as pleasant to use as pyplot... I
don't know the codebase well enough to mess with this right now, so I
hope someone who's more versed in that part of the code can make a fix
for this whose impact isn't too severe on the runtime of OO code.
I'm not very inclined to this but I'll wait to hear what others think.
I use oo api in the interactive mode but I still prefer to call draw()
explicitly.
Of course, we can make it optional.
By the way, given that we now have suplots in the pyplot namespace,
can we have sca also?
For example,
# Two subplots, the axes array is 1-d
f, axarr = subplots(2, sharex=True)
sca(axarr[0])
plot(x, y)
title('Sharing X axis')
sca(axarr[1])
scatter(x, y)
Or, how about we make axes an context manager.
# Two subplots, the axes array is 1-d
f, axarr = subplots(2, sharex=True)
with axarr[0]:
plot(x, y)
title('Sharing X axis')
with axarr[1]:
scatter(x, y)
This may not very useful in the interactive mode, but may make a
script (written in pylab mode) more readable.
Regards,
-JJ
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Jae-Joon Lee wrote:
By the way, given that we now have suplots in the pyplot namespace,
can we have sca also?
Done in svn 8205.
For example,
# Two subplots, the axes array is 1-d
f, axarr = subplots(2, sharex=True)
sca(axarr[0])
plot(x, y)
title('Sharing X axis')
sca(axarr[1])
scatter(x, y)
Or, how about we make axes an context manager.
This would require dropping support for Python 2.4.
Eric
# Two subplots, the axes array is 1-d
f, axarr = subplots(2, sharex=True)
with axarr[0]:
plot(x, y)
title('Sharing X axis')
with axarr[1]:
scatter(x, y)
This may not very useful in the interactive mode, but may make a
script (written in pylab mode) more readable.
Regards,
-JJ
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Fernando Perez wrote: I personally think that this should be the way to use mpl in general when scripting, and the way I want to teach, + Inf ! I've wanted to do this for years (make a easier way to do scripting the OO way), but I only get around to a tiny fraction of the things I want to do. For this reason, I think the name should be really well chosen, and I'm not convinced fig_subplot is a very good one. I'll leave the name decisions to you folks, I just wanted to be encouraging! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Fernando Perez wrote: Howdy, On Wed, Feb 24, 2010 at 11:27 AM, Fernando Perez fperez@gmail.com wrote: OK, since I know people are busy, I took silence as acquiescence. Committed in r8151, please let me know if I messed anything up and I'll try to fix it. I'm used to the numpy docstring standard, but I tried to adapt it to the mpl one by looking at the rest of pyplot, let me know if it needs fine-tuning. While chatting today with John, he suggested that a better api for this would be to return an *array* of supblots, so that one could index them with a[i,j] for the plot in row i, column j. I've implemented this already, but before committing it, I have one doubt: what to do when nrows==ncols==1, the single subplot case? I'm inclined to return only the subplot instead of a one-element array, so that one can say f, a = fig_subplot() a.plot(...) instead of having to do f, a = fig_subplot() a[0].plot(...) But this means the return value of the function would be: - fig, axis if nr=nc=1 - fig, axis_array in all other cases. The behavior one wants depends on whether one is calling fig_subplot in a program in which the number of subplots could range from 0 to n, or whether the call is being made with the number of subplots hardwired. The latter may be most common, but the former seems like an important use case. I suggest providing a kwarg, e.g. squeeze=True as the default, to eliminate zero-size-dimensions from the array, and False for the case where nrows and/or ncols could be zero but one wants to be able to iterate over the resulting array regardless. Eric so it's a bit ugly. I think this is a case where practicality beats purity and my nose tells me to go for the less pretty but more convenient api, but I'm happy to get feedback. The return code reads currently: # Reshape the array to have the final desired dimension (nrow,ncol), though # discarding unneeded dimensions that equal 1. If we only have one # subplot, just return it instead of a 1-element array. if nplots==1: return fig, axarr[0] else: return fig, axarr.reshape(nrows, ncols).squeeze() Once we settle this design decision, I'll update the docstring and example and will post the patch for final review before committing. Cheers, f -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 12:20 PM, Eric Firing efir...@hawaii.edu wrote: Fernando Perez wrote: While chatting today with John, he suggested that a better api for this would be to return an *array* of supblots, so that one could index them with a[i,j] for the plot in row i, column j. I've implemented this already, but before committing it, I have one doubt: what to do when nrows==ncols==1, the single subplot case? I'm inclined to return only the subplot instead of a one-element array, so that one can say f, a = fig_subplot() a.plot(...) instead of having to do f, a = fig_subplot() a[0].plot(...) But this means the return value of the function would be: - fig, axis if nr=nc=1 - fig, axis_array in all other cases. The behavior one wants depends on whether one is calling fig_subplot in a program in which the number of subplots could range from 0 to n, or whether the call is being made with the number of subplots hardwired. The latter may be most common, but the former seems like an important use case. I suggest providing a kwarg, e.g. squeeze=True as the default, to eliminate zero-size-dimensions from the array, and False for the case where nrows and/or ncols could be zero but one wants to be able to iterate over the resulting array regardless. +1 This feels like a clean solution to the problem. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Fernando Perez wrote: While chatting today with John, he suggested that a better api for this would be to return an *array* of supblots, so that one could index them with a[i,j] for the plot in row i, column j. That would be nice. implemented this already, but before committing it, I have one doubt: what to do when nrows==ncols==1, the single subplot case? I'm inclined to return only the subplot instead of a one-element array, so that one can say f, a = fig_subplot() a.plot(...) instead of having to do f, a = fig_subplot() a[0].plot(...) But this means the return value of the function would be: - fig, axis if nr=nc=1 - fig, axis_array in all other cases. actually, wouldn't there be three options, essentially: scalar, 1-d, 2-d so the second example might be. f, a = fig_subplot() a[0,0].plot(...) Eric Firing wrote: The behavior one wants depends on whether one is calling fig_subplot in a program in which the number of subplots could range from 0 to n, or whether the call is being made with the number of subplots hardwired. good point. The latter may be most common, but the former seems like an important use case. I suggest providing a kwarg, e.g. squeeze=True as the default, to eliminate zero-size-dimensions from the array, and False for the case where nrows and/or ncols could be zero but one wants to be able to iterate over the resulting array regardless. this feels a bit ugly to me as well, though not too bad. Maybe this is too much magic, but could you look at what was passed in to the subplot call: I don't remember if you are following the figure.add_subplot() api, but: If nothing, then the user is clearly asking for a single axis. if (r,c,n) then the user is specifying a 2-d arrangement, even if r and c happen to be 1. I think the only two options should be scalar or 2-d array, it seems a bit much to have a 1-d array option as well. Also, IIUC correctly, Figure.add_subplot always returns a SINGLE axis -- you have to call it multiple times to get the whole set. Does this version return the whole set? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 1:38 PM, Christopher Barker chris.bar...@noaa.gov wrote: I think the only two options should be scalar or 2-d array, it seems a bit much to have a 1-d array option as well. I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is natural. This is also the most common use case so the most important to get right. If you aren't doing multiple subplots, a plain ol subplot(111) may be preferred to fig_subplots anyhow. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
John Hunter wrote: I think the only two options should be scalar or 2-d array, it seems a bit much to have a 1-d array option as well. I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is natural. This is also the most common use case so the most important to get right. OK, but then how do you handle the fact that you might get a 0-d, 1-d or 2-d result? Eric's squeeze flag would result in that. Having squeeze1d and squeeze2d flags seems a bit much. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 2:24 PM, Christopher Barker chris.bar...@noaa.gov wrote: John Hunter wrote: I think the only two options should be scalar or 2-d array, it seems a bit much to have a 1-d array option as well. I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is natural. This is also the most common use case so the most important to get right. OK, but then how do you handle the fact that you might get a 0-d, 1-d or 2-d result? Eric's squeeze flag would result in that. Having squeeze1d and squeeze2d flags seems a bit much. squeeze configured with a kwarg seems like a good compromise. As long as the behavior is well documented it shouldn't pose any problems. And we still have access to fig.axes in the same format is has always been in. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 11:47 AM, John Hunter jdh2...@gmail.com wrote: I disagree here -- if you are 2,1 or 1,2 rows x cols, 1D indexing is natural. This is also the most common use case so the most important to get right. If you aren't doing multiple subplots, a plain ol subplot(111) may be preferred to fig_subplots anyhow. I agree with John that for nx1 or 1xn, 1-d indexing seems more natural, and is the more pythonic solution given how numpy doesn't distinguish between row and column arrays when they are 1-d, in contrast to matlab. This is why I went for the approach above. Based on the feedback, I'll finish it tonight with squeeze=True as a kwarg, that behaves: - if True (default): single axis is returned as a scalar, Nx1 or 1xN are returned as numpy 1-d arrays, and only NxM with N1 and M1 are returned as a 2d array. - if False, no squeezing at all is done, the return value is always a 2-d array, even if it ends up being 1x1. I think this gives a very convenient interactive/lightweight scripting interface, while letting application builders who may need to write generic code that is dimension agnostic have robust code that needs no special-casing by passing squeeze=False. Unless I hear otherwise, I'll make the commit with these changes (updating the docstring and example script accordingly). Cheers, f -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Fernando Perez wrote: Based on the feedback, I'll finish it tonight with squeeze=True as a kwarg, that behaves: - if True (default): single axis is returned as a scalar, Nx1 or 1xN are returned as numpy 1-d arrays, and only NxM with N1 and M1 are returned as a 2d array. - if False, no squeezing at all is done, the return value is always a 2-d array, even if it ends up being 1x1. Good solution, and thanks for working on this! -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Mar 18, 2010 at 7:46 PM, Fernando Perez fperez@gmail.com wrote: On Thu, Mar 18, 2010 at 3:49 PM, Christopher Barker chris.bar...@noaa.gov wrote: Good solution, and thanks for working on this! Thanks. I have one more question on this feature. I personally think that this should be the way to use mpl in general when scripting, and the way I want to teach, because it's easy and short while encouraging access to more robust patterns (figure/axes handing instead of the stateful pyplot). For this reason, I think the name should be really well chosen, and I'm not convinced fig_subplot is a very good one. I know naming discussions can be annoying, but if this ends up being the most popular/common entry point for making plots, it may be worth spending a moment on picking it right. Ideas (I'm *awful* at naming)? - plot_array? - plots? - subplots? - parray? - plotarr? - something actually good from someone else? I'll finish the patch tonight, we can always fix the name later as it's a trivial search/replace on fig_subplots - new_great_name. I also think the name should be changed, and there should be an entry in the matplotlib.figure.Figure API. One additional suggestion is subarray and matplotlib.pyplot.subarray would be a thin wrapper to matplotlib.figure.Figure.add_subarray. The former would return (fig, axarray) using gcf() to get the current figure, and the latter would simply create the subarray and return it. The would break a bit with the pyplot axes and subplot commands that only return the Axes and Subplot instances (and not the implicit Figure instance created/used) but I can live with that because part of the goal here is to give easy access to axes and figure creation so the user can get in the habit of using the API directly for most things. As for the other name suggestions, I like subplots. JDH -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Tue, Feb 23, 2010 at 10:14 PM, Fernando Perez fperez@gmail.com wrote: Final question: should I put the little demo code at the bottom that I used for testing this up in an example file? I put some of that in the docstring as an example, but not all to avoid clutter. OK, since I know people are busy, I took silence as acquiescence. Committed in r8151, please let me know if I messed anything up and I'll try to fix it. I'm used to the numpy docstring standard, but I tried to adapt it to the mpl one by looking at the rest of pyplot, let me know if it needs fine-tuning. Cheers, f -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Sat, Feb 20, 2010 at 3:50 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: 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. OK, thanks for the feedback. I've just finalized it here: http://gfif.udea.edu.co/idf/indefero/www/index.php/p/mscomp-2010/source/tree/master/0217/figsubp.py Knowing now that the sharing doesn't have an actual master/slave relationship (like the existing examples suggest since they appear to require an explicit index for sharing), the actual implementation was really trivial in the end. It might be a good idea to clarify this in the main docs, the current examples make axis sharing look harder than it actually is (all those tricks with order creation I was playing are completely unnecessary). If you all like this API, I'm happy to push into the real svn repo. Final question: should I put the little demo code at the bottom that I used for testing this up in an example file? I put some of that in the docstring as an example, but not all to avoid clutter. Cheers, f -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Feb 18, 2010 at 11:50 PM, Fernando Perez fperez@gmail.com 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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:50 PM, Fernando Perez fperez@gmail.com 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 -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
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/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:17 PM, John Hunter jdh2...@gmail.com 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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Thu, Feb 18, 2010 at 8:02 AM, John Hunter jdh2...@gmail.com 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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
Howdy On Thu, Feb 18, 2010 at 1:19 PM, Jae-Joon Lee lee.j.j...@gmail.com 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 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
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/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
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 -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 7:27 PM, David Warde-Farley d...@cs.toronto.edu 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 -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 8:29 PM, Fernando Perez fperez@gmail.com wrote: On Wed, Feb 17, 2010 at 7:27 PM, David Warde-Farley d...@cs.toronto.edu 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 -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] An easier way to create figure and group of axes; useful?
On Wed, Feb 17, 2010 at 10:17 PM, John Hunter jdh2...@gmail.com 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 -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
