gnuplot-py-users Mailing List for Gnuplot.py

Michael Haggerty wrote:
> Well, I have to say that I would like to keep a "clean" interface on the 
> Gnuplot class--that is to say, easily understandable, straightforward to 
> implement, and without too many special cases.  This can include some of 
> the features suggested but not all of them.  Then I think it would be 
> excellent to derive from it an "interactive Gnuplot" class with any 
> other hairy and terse convenience features, special cases, and whatever 
> else that people want.  Of course we can make any reasonable changes to 
> the Gnuplot class that are needed to allow the derived class to be 
> implemented.

That makes perfect sense.  My ipython code is _somewhat_ structured in that 
matter, with GnuplotInteractive and GnuplotRuntime modules meant for easier 
interactive/scripting use respectively.  I'm sure you can organize things 
somewhat differently, but that might be a start (after all, the code is 
already written and works).

> 
> Let's put together a wish list for the "interactive Gnuplot" class and 
> then decide how to split the implementation between the old and the new 
> class.
> 
> One feature that definitely can go into the Gnuplot class is the special 
> conversion of 1-D arrays into datasets with one column.

My personal 'wishlist' is basically the existing code in ipython.  I've pretty 
much put in everything I wanted (or most things, at least) in there. The files 
are:

[IPython]> ls Gnu*py
Gnuplot2.py -- rewrite of the code I wanted to actually modify
GnuplotInteractive.py  GnuplotRuntime.py  -- thin wrappers for 
interactive/scripting use.

You (whoever does the actual work :) would probably want to move some of my 
more intrusive changes out of the Gnuplot2 code and put them into the upper 
layers, and keep some of the less intrusive stuff (and bugfixes like the 
hardcopy one) in Gnuplot.py-mainline.

> Based on recent performance, it is pretty clear that I won't have time 
> for a lot of new implementation soon, so ideally somebody would 
> volunteer to work on "interactive Gnuplot" features.  (I could commit to 
> make any necessary changes to the main Gnuplot classes.)  I can give 
> that person write permission on CVS at sourceforge so you can work 
> independently.  Anyone?

Unfortunately, my hands are more than full with ipython.  Ipython is about as 
much as I can handle right now beyond 'real work', and there are some 
substantial changes I want to do which will take all of my available time.

But the existing code in ipython could be hopefully used to jumpstart things, 
and I'll gladly assist with discussion/changes to that.  If there are any 
licensing/copyright changes that you may want done, I'm perfectly happy making 
them.

Cheers,

f.

Fernando Perez wrote:

> Leonardo Milano wrote:
>
>> So, in short, I agree there is a need for the functionality
>> Fernando is suggesting, the question is HOW to implement it.
>
>
> Well, your approach and mine are slightly different in the details.  
> But ultimately it's Michael's call.  I just recently put out 
> 'officially' ipython 0.4.0 with all the recent enhancements (some of 
> which are related to Gnuplot support).  When Michael has a chance, 
> he'll probably have a look and decide how much to use/change for the 
> mainline code.


Well, I have to say that I would like to keep a "clean" interface on the 
Gnuplot class--that is to say, easily understandable, straightforward to 
implement, and without too many special cases.  This can include some of 
the features suggested but not all of them.  Then I think it would be 
excellent to derive from it an "interactive Gnuplot" class with any 
other hairy and terse convenience features, special cases, and whatever 
else that people want.  Of course we can make any reasonable changes to 
the Gnuplot class that are needed to allow the derived class to be 
implemented.

Let's put together a wish list for the "interactive Gnuplot" class and 
then decide how to split the implementation between the old and the new 
class.

One feature that definitely can go into the Gnuplot class is the special 
conversion of 1-D arrays into datasets with one column.

Based on recent performance, it is pretty clear that I won't have time 
for a lot of new implementation soon, so ideally somebody would 
volunteer to work on "interactive Gnuplot" features.  (I could commit to 
make any necessary changes to the main Gnuplot classes.)  I can give 
that person write permission on CVS at sourceforge so you can work 
independently.  Anyone?

Michael

-- 
Michael Haggerty
mh...@al...

Leonardo Milano wrote:

> So, in short, I agree there is a need for the functionality
> Fernando is suggesting, the question is HOW to implement it.

Well, your approach and mine are slightly different in the details.  But 
ultimately it's Michael's call.  I just recently put out 'officially' ipython 
0.4.0 with all the recent enhancements (some of which are related to Gnuplot 
support).  When Michael has a chance, he'll probably have a look and decide 
how much to use/change for the mainline code.

In the meantime, ipython users still can use those enhancements (if they like 
them :)

Best,

f.

Hi Michael, Hola Fernando, All :-)

I have done some tricks very similar to Fernando's
independently, there is perhaps some real need for
a set of simplified methods in gnuplot, to make its
use a little friendlier. But I am not sure what is the
best way to go. Add some methods ? Create a higher
level interface to gnuplot ?. Don't know.

I'll post my solutions briefly:

[1] I inherit my own myGnuplot(Gnuplot) to extend Gnuplot as I need
[2] I wrote an external functions to do quick plots

In the first case I handle the terminal setting to postscrip, x,
etc. I use reasonable (for my use) default values. So a ps plot goes
like this:

    g.set_ps('filename.ps')
    g.plot(whatever)
    g.set_x()

In the second case I am able to do quick plots from an interactive
shell, just call qplot(y), or qplot(x,y), or plot(x,y1,y2) ... etc

So, in short, I agree there is a need for the functionality
Fernando is suggesting, the question is HOW to implement it.

Thank you all for your time. Cheers,
-- Leo

PS: So, here is the code:


[1] #### Gnuplot extension methods

class myGnuplot(Gnuplot.Gnuplot):
    # [...]
    def set_eps(self, filename, options = 'enhanced color "Times-Roman" 22'):
        self('set terminal postscript eps ' + options)
        self('set output "' + filename + '"')

    def set_ps(self, filename, options = 'enhanced color "Times-Roman" 22'):
        self('set terminal postscript ' + options)
        self('set output "' + filename + '"')

    def set_x(self):
        self('set terminal x11')

[2] #### quick plot function

def qplot(x, y1=arange(0), y2=arange(0), y3=arange(0)):
    """
    Quick plot Routine

    USAGE::

        qplot(y)          # plots y as a function of a vector [0,1,...,size(y)]
        qplot(x,y)        # plots y(x)
        qplot(x,y1,y2)    # plots y1(x) and y2(x)
        qplot(x,y1,y2,y3) # plots y1(x), y2(x) and y3(x)
    """

    g  = myGnuplot(persist=1, debug=1)
    g('set data style lines')

    if  size(y1) == 0:
        d1 = Data(arange(size(x)), x)
        g.plot(d1, xlabel = "x", ylabel="y")
    elif size(y2) == 0:
        d1 = Data(x, y1, title="y1")
        g.plot(d1, xlabel = "x", ylabel="y")
    elif size(y3) == 0:
        d1 = Data(x, y1, title="y1")
        d2 = Data(x, y2, title="y2")
        g.plot(d1, d2, xlabel = "x", ylabel="y")
    else:
        d1 = Data(x, y1, title="y1")
        d2 = Data(x, y2, title="y2")
        d3 = Data(x, y3, title="y3")
        g.plot(d1, d2, d3, xlabel = "x", ylabel="y")

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.

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

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.

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.

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.

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

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

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

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

Please let me know what version of Gnuplot.py was your starting point so 
that I can download IPython and use diff to see your changes.

Thanks again!
Michael

Fernando Perez wrote:

> I've been a longtime user of your Gnuplot.py modules, so much so that 
> I've written a fair amount of stuff which wraps around them and 
> extends them to make everyday life easier.  First, thanks a lot for 
> putting out such a useful tool.
>
> Some of the changes I've made are for example a rewrite of the plot 
> command to handle cases like
>
> -plot(y) -> plot a NumPy array against its indices
> -plot(x,y) -> plot y vs x
> -plot(y1,None,y2) -> plot y1,y2 vs their indices (None is a separator)
> -plot(y,filename='out.eps') -> make eps output reliably (there's a 
> tricky timing issue which requires retrying the print command with a 
> sleep())
>
> - 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.
>
> ... plus a bunch of other stuff I don't remember now.  I made all of 
> these changes with the main objective of easing interactive use as 
> much as possible, so that the least amount of typing at the command 
> line would produce the most results.
>
>
> I've been including all of this in IPython for a long time 
> (http://ipython.scipy.org), and I wrap it in such a way as to make its 
> use fairly transparent.  But I think that most of this code should go 
> into the mainline of your project.  This would ease my maintenance 
> burden :), plus it would benefit all users of Gnuplot.py who don't 
> necessarily use IPython.  I could then leave a very thin layer in 
> IPython, mainly just for interactive use (though perhaps even that 
> should be a Gnuplot.py sub-module, something like Gnuplot.Interactive 
> or somesuch).
>
> Anyway, if you think you are interested in this, why don't you take a 
> look at IPython?  If you download it, you'll immediately see the 
> Gnuplot-related files.  You can then have a look and we can discuss if 
> you want to integrate the code, and what the best approach would be.
>
> [...]
>
> Best regards,
>
> Fernando Perez. 


-- 
Michael Haggerty
mh...@al...