Menu
▾
▴
matplotlib-devel
|
From: Jae-Joon L. <lee...@gm...> - 2010-03-22 15:58:47
|
On Sun, Mar 21, 2010 at 8:10 PM, Fernando Perez <fpe...@gm...> 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 |
|
From: Eric F. <ef...@ha...> - 2010-03-18 17:20:22
|
Fernando Perez wrote: > Howdy, > > On Wed, Feb 24, 2010 at 11:27 AM, Fernando Perez <fpe...@gm...> 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® 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
|
From: Ryan M. <rm...@gm...> - 2010-03-18 18:24:00
|
On Thu, Mar 18, 2010 at 12:20 PM, Eric Firing <ef...@ha...> 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 |
|
From: Christopher B. <Chr...@no...> - 2010-03-18 19:18:33
|
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/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... |
|
From: John H. <jd...@gm...> - 2010-03-18 19:31:08
|
On Thu, Mar 18, 2010 at 2:24 PM, Christopher Barker <Chr...@no...> 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 |
|
From: Christopher B. <Chr...@no...> - 2010-03-19 18:51:49
|
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/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... |
|
From: Eric F. <ef...@ha...> - 2010-03-21 00:40:27
|
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
|
|
From: Jae-Joon L. <lee...@gm...> - 2010-03-21 21:42:47
|
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> 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
|
|
From: Jae-Joon L. <lee...@gm...> - 2010-03-21 17:36:20
|
On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> 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 |
|
From: Ryan M. <rm...@gm...> - 2010-03-21 17:50:53
|
On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee <lee...@gm...> wrote: > On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> 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 |
|
From: Eric F. <ef...@ha...> - 2010-03-21 18:31:07
|
Ryan May wrote: > On Sun, Mar 21, 2010 at 12:35 PM, Jae-Joon Lee <lee...@gm...> wrote: >> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...> 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 > |
|
From: Jae-Joon L. <lee...@gm...> - 2010-03-21 20:07:56
|
On Sun, Mar 21, 2010 at 2:30 PM, Eric Firing <ef...@ha...> wrote:
> 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.
>
* complexity
I guess the code below is a "minimal" implementation (it worked okay with
my limited tests).
# context manager
def __enter__(self):
import matplotlib.pyplot as plt
plt.sca(self)
return self
def __exit__(self, type, value, tb):
pass
* readability
1) with "with" statement
fig, axarr = subplots(2,2)
> for ax1, ax2 in axarr:
with ax1:
plot([1,2,3])
> with ax2:
plot([2,3,4])
2) with "sca"
> fig, axarr = subplots(2,2)
> for ax1, ax2 in axarr:
sca(ax1)
plot([1,2,3])
> sca(ax2)
plot([2,3,4])
While I certainly prefer 1) over 2) as far as the readability is concerned,
I currently don't have a strong opinion whether the readability beats the
complexity in this case.
So, unless there are more of positive feedbacks from others, I'll consider
it dropped.
Regards,
-JJ
|
|
From: Eric F. <ef...@ha...> - 2010-03-21 22:08:07
|
Jae-Joon Lee wrote:
>
>
> On Sat, Mar 20, 2010 at 8:40 PM, Eric Firing <ef...@ha...
> <mailto:ef...@ha...>> 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
|
|
From: Jae-Joon L. <lee...@gm...> - 2010-03-21 22:22:51
|
On Sun, Mar 21, 2010 at 6:07 PM, Eric Firing <ef...@ha...> 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 |
|
From: Jörgen S. <jor...@bo...> - 2010-03-22 18:04:00
|
Fernando Perez skrev 2010-03-22 01:10: > On Sat, Mar 20, 2010 at 4:00 PM, Jae-Joon Lee<lee...@gm...> wrote: >> On Sat, Mar 20, 2010 at 5:05 AM, Fernando Perez<fpe...@gm...> 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 |
|
From: John H. <jd...@gm...> - 2010-03-22 21:08:24
|
On Mon, Mar 22, 2010 at 11:50 AM, Jörgen Stenarson <jor...@bo...> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X