|
From: Fernando P. <fp...@co...> - 2003-05-16 06:51:44
|
Michael Haggerty wrote:
> Hi Fernando,
>
> Thanks for your message! I will download IPython and look at what
> you've done. Unfortunately, it might take a while as I'm really busy
> with work and an infant :-(
No problem, there's no rush whatsoever (some of this code is over a year old,
I just hadn't gotten around to contacting you). Congratulations on fatherhood :)
> I'm forwarding this message to the Gnuplot-py-users mailing list so that
> other users can see your ideas and comment on them. If you haven't
> already done so, I suggest you subscribe to this list.
Done. In fact, I'm cc-ing the list here.
>
> By the way, are your changes relative to version 1.6 or relative to some
> CVS version? CVS has lots of changes and new features that I haven't
> gotten around to releasing yet so you might want to have a look at it.
Everything I've done is against 1.5, but I haven't really modified your code
at all. All of my changes live inside ipython, and I just import the
unmodified Gnuplot module, and then at runtime overwrite a few methods here
and there with my own. The beauty of python's dynamism :) This approach
means that all Gnuplot.py users can get my modifications without having to
patch their installation or get a special version.
I tried to do as much as I could with subclassing, but in a few places I had
to pick up your code and put in the modified version straight inside ipython.
> Some quick comments regarding your specific ideas:
>
> > -plot(y) -> plot a NumPy array against its indices
>
> I guess this is a special case if y has only one dimension? Sounds good.
Right. Quite useful to get a quick look at an array without having to do the
plot(Data(zip(range(len(y)),y))) dance. plot(y) is easier :)
> > -plot(x,y) -> plot y vs x
>
> I find this special case confusing because each argument to plot() is
> usually a single PlotItem. Instead of this you can type
> plot(Data(x,y)), which isn't much more typing and is unambiguous.
I do this because plots of the type y vs x are such a common occurrence, that
I wanted a 'zero-effort' syntax to do the 'right thing'. When I'm playing
with numerical stuff at the command line, even typing the additional Data()
every time seems like too much. Call me lazy :)
I'd like you to give it a try before you make up your mind. The way I wrote
it, it doesn't break any of the existing usage cases at all, but it offers a
lighter syntax for many common situations. I've used it extensively for over
a year, and I really like it. I can always keep the modifications inside
ipython for my own use if you really disagree, since I won't give them up :)
But after playing with them a bit, you may get to like them.
> > -plot(y1,None,y2) -> plot y1,y2 vs their indices (None is a separator)
>
> This even more confusing special case wouldn't be necessary if not for
> the previous one.
Well, it's just that I'm often computing things in various ways and need to
quickly see all of them. This allows me to plot a bunch of arrays of the same
length without having to build Data() objects with zip(range(len...)) calls
every time. Again, this is all about having a very light syntax that I can
use repeatedly at the command-line.
> > -plot(y,filename='out.eps') -> make eps output reliably
> > (there's a tricky timing issue which requires
> > retrying the print command with a sleep())
>
> Isn't this what hardcopy() does? What is the advantage of this call vs.
> hardcopy()? If hardcopy has the timing problem you mention, I would be
> very interested to hear more details. (By the way, hardcopy() has
> really been improved in CVS; you should check it out if you haven't
> already.)
Yes, it ultimately calls (my modified) hardcopy. The point was to allow one
to make hardcopy _without_ having built a plot before (think of the case where
you are running a script which batch-generates tens of plots). The previous
system would require
plot(....) -> may fail if the there is no x-server in a batch job
hardcopy()
Quoting the ipython docs:
PostScript generation through plot() is useful mainly for scripting
uses where you are not interested in interactive plotting. For
interactive use, the hardcopy() function is typically more convenient:
I've found this option to be very convenient after extensive use. I had a
large make-type file which was in reality a python script for generating all
of the plots in my thesis from the raw data. I could change some global
options (fonts, color/mono, etc) and simply type ./plots.py, and get every
single plot rebuilt in a few minutes. In this kind of situation, I don't want
to see a few hundred gnuplot windows pop up :)
I ran into the timing problem and spent a _lot_ of time trying to debug it.
Basically, under Linux hardcopy turned out to be randomly unreliable.
Sometimes it would exit without having truly created the eps file. My
brute-force solution was to force a loop which tries to make the file 20 times
with a small sleep() delay. If after 20 attempts it can't make it, it gives
up and informs the user. After I put that in, I haven't seen any more
problems. The bug is subtle and annoying enough (when it pops up, which is
rather random) that I wanted a bulletproof fix, even if ugly.
>
> > - Added the 'index' keyword arg to File, similar to Gnuplot's
> > index option to select a dataset from a file with multiple
> > datasets in it.
>
> Sounds good.
Best regards,
Fernando.
|