gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Mac OS X driver.

[Hans-Bernhard B. <br...@ph...>]

On Tue, 30 Mar 2004, Ethan Merritt wrote:

> On Tuesday 30 March 2004 01:17 pm, Per Persson wrote:
> > 
> > I was a little curious about the reason for the overlap between
> > filled_polygon() and boxfill(), any particular reason?
> 
> Two parallel projects that got incompletely merged.

That's not the entire truth, though.  There's also the problem that doing
cross-hatching pattern-fill of arbitrary polygons is at least an order of
magnitude harder than either cross-hatching of axis-aligned rectangles or
solid-colour filling of arbitrary polygons.

> the job, I'll probably do it as part of general code cleanup 
> eventually.

That'll be a good deal more work than just a little clean-up.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: hidden3d very slow in gnuplot 3.8k

[Hans-Bernhard B. <br...@ph...>]

On Wed, 31 Mar 2004, Glyn Edwards wrote:

> Hi, I have been plotting some data I have that has a large number of
> points say 500x300. I have noticed that this is considerably slower in
> gnuplot 3.8 that 3.7.3, so much so that i have reverted back to the
> previous version. Has anyone else come across this?

The root of this problem is 500x300 is a rather excessive number of 
points to plot as a wireframe mesh.  You'll want to build gnuplot with
the undocumented flag -DTEST_QUADTREE=1 in this case.

The basic problem is that a hidden-line removal algorithm in a setting
like gnuplot's terminal API, which cannot rely on erasing any portion of a
line after it has been drawn, has an unescaple worst-case behaviour of
O(N^2) for input size N (number of points, polygons or edges), and
gnuplot's hidden3d code in default compilation will even have an expected
O(N^2).  It essentially tests every edge in the mesh against every
triangle.  That'll be a small factor times (2*2*500x300)^2 = 3.6e11 tests,
which _will_ take rather a lot of time, even with the highly optimized way
the tests are done.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

hidden3d very slow in gnuplot 3.8k

[Glyn E. <gly...@fa...>]

Hi, I have been plotting some data I have that has a large number of
points say 500x300. I have noticed that this is considerably slower in
gnuplot 3.8 that 3.7.3, so much so that i have reverted back to the
previous version. Has anyone else come across this?

Glyn
-- 
  Glyn Edwards
  gly...@fa...

-- 
http://www.fastmail.fm - I mean, what is it about a decent email service?

Re: Mac OS X driver.

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 30 March 2004 01:17 pm, Per Persson wrote:
> 
> I was a little curious about the reason for the overlap between
> filled_polygon() and boxfill(), any particular reason?

Two parallel projects that got incompletely merged.

The boxfill() routine was added as part of Ule Gruenebaum's
work to allow solid-fill and pattern-fill boxes in the existing
plot styles.

The filled_polygon() routine was part of Petr Mikulik's large
PM3D code block that does 3D surface-plots and allows
color-mapping a Z-range to a color palette.

Both of these code blocks were marked as EXPERIMENTAL
during much of the version 3.8 development, and were worked
on by different people.  In retrospect they probably should have
been merged earlier, but they weren't.  If nobody else tackles
the job, I'll probably do it as part of general code cleanup 
eventually.

This sort of thing can happen in particular because new
features tend to get implemented first for a restricted set
of terminal drivers. It is only when they are later expanded
to a more complete set, or get abstracted to a higher layer
of the code, that they collide. 


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

No 16-bit binaries.

[Hans-Bernhard B. <br...@ph...>]

Hello, gents,

I've now decided against making any 16-bit binaries of 4.0.  The poll
in c.g.a.gnuplot showed not a single hands-up, i.e. the need for such
a version is apparently zero.

A line in the 4.0 announcement should state this.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: More fallout from TBOOLEAN change - hidden3d broken

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:

>On Mon, 29 Mar 2004, Daniel J Sebald wrote:
>
>  
>
>>That fixes things and is fine.  However, v1_inside_p and v2_inside_p do 
>>have the feel of Boolean variables.  
>>    
>>
>
>They're not, at least not really.  classification[i] is a two-bit
>variable, by design, and thus v1_inside_p is, too.  It's used mostly like
>a boolean later on, but that's a different story.
>

Right.  But "v1 inside p", that's a yes or no question.  No?  In other 
words a Boolean.

Dan

Re: [Fwd: Re: V4 -final touches]

[Petr M. <mi...@ph...>]

> > >No, the FAQ location is OK -- so maybe now it is time to redirect
> > >www.gnuplot.info to gnuplot.sf.net
> >
> > I'd be more inclined to get the mirroring right.  If we need to
> > establish different mirror than from Lars's, then we should work on
> > that.  The sf site was intended for developer use, not end-user use.
>
>  And the UCC site was intended as a stop-gap, until someone finds the
>  time to set up something better at www.gnuplot.info.

I think www.gnuplot.info and gnuplot.sf.net should have the same content.
Developer web pages (if somebody will write them) will be inside it --
there is already item "Current development".


---
PM

Re: More fallout from TBOOLEAN change - hidden3d broken

[Hans-Bernhard B. <br...@ph...>]

On Mon, 29 Mar 2004, Daniel J Sebald wrote:

> That fixes things and is fine.  However, v1_inside_p and v2_inside_p do 
> have the feel of Boolean variables.  

They're not, at least not really.  classification[i] is a two-bit
variable, by design, and thus v1_inside_p is, too.  It's used mostly like
a boolean later on, but that's a different story.

> probably shouldn't be.  Also, doing the bit shift on the variable is 
> extraneous.  

It may be now, but I don't think it was when I introduced it.  This
hidden3d stuff is seriously tricky, and it developed incrementally, so not
all of the stuff you see in there right now may make complete sense.

As a matter of fact, the entire statement sequence involving v?_inside_p
can be simplified to:

	    if (! (classification[0]
		   | classification[1]
		   | classification[2])) {

I'm checking in a modification along those lines.  It'll also unify some
cases where convenience copies of TBOOLEAN pm3d_color_from_column were
kept in ints.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: More fallout from TBOOLEAN change - hidden3d broken

[Hans-Bernhard B. <br...@ph...>]

On Mon, 29 Mar 2004, Per Persson wrote:


> That change to TBOOLEAN was for the benefit of Mac OS X if I understand 
> correctly.

Yes.  The Mac OS X build seemed to be pulling in an override definition of
type "bool" from some system header file, long *after* syscfg.h had 
already defined it.  That broke the compilation.

> Just so everybody knows what options we have, that change is *not*
> necessary anymore, with the new aquaterm.trm.

I.e. if you had come out of the bush a week or two earlier, none of this
would have been discovered before 4.0.  I'll leave it to everyone's own
deliberation whether this is a good thing or a bad.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: V4 -final touches

[Hans-Bernhard B. <br...@ph...>]

On Mon, 29 Mar 2004, BBands wrote:

> On Win2k you also get the following, two lines below Send... and
> indented one additional space.
> 
>           Send...
> 
>            warning: no HOME found

That's the mechanism for expanding filenames like '~/mygnuplot/script.gpl'
trying to find what it should use for ~.  That message can be avoided by
setting the environment variable HOME.  The equivalent of

	set HOME=%USERPROFILE%

should work.  I think I'll go and add code to fall back to %USERPROFILE%
if HOME isn't defined to the relevant place.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: More fallout from TBOOLEAN change - hidden3d broken

[Hans-Bernhard B. <br...@ph...>]

On Mon, 29 Mar 2004, Ethan Merritt wrote:

> Is there a tool (or gcc compile option) that will
> double check for illegal operations on our TBOOLEANs? 

"Splint" comes to mind.  OTOH, we currently have O(1000) splint warnings
in gnuplot, so that may not be a particularly easy thing to check.

> made the problem go away, so this was another
> bit of fallout from the TBOOLEAN change.
> 
> hidden3d.c line 817:
>         casenumber = (plist[new_poly].frontfacing != 0)
>             + 2 * (plist[old_poly].frontfacing != 0);

Guilty as charged --- hidden3d is fully my own responsibility ;-( I'll
double-check the fixes.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [Fwd: Re: V4 -final touches]

[Daniel J S. <dan...@ie...>]

Oh.  Bummer.  It is interesting that in the short period of time it took 
for you to address the re-registration, this person must have had some 
way of knowing that a valid registered URL expired and hence scooped it 
up.  Anyway, I think this would fall under the ICANN's uniform 
domain-name dispute-resolution policy:

http://www.icann.org/udrp/udrp.htm

That sounds like "cybersquatting" and unless this person has some type 
of valid claim to such a URL name, he would have to give it up, I think, 
to someone with a more valid claim.  However, "gnuplot" isn't a 
trademarked name by developers... which would be the convincing evidence 
that it should be relinquished.  Furthermore, the fees for arbitration 
are probably prohibitive in this situation.

I guess a Jack Handy quote is in order: "If you ever drop your keys into 
a river of molten lava, let'em go, because, man, they're gone."

Dan


John A. Turner wrote:

> Daniel J Sebald wrote:
>
>> Yes, the less "location dependent" the address the better, even if it 
>> simply serves as an alias and gets resolved somewhere else.  
>> (Although .info seems unconventional, but big woop.)
>
>
> that's a long, sad, frustrating story that still angers me every time
> I think about it
>
> the short version is that I registered gnuplot.org for the project
> several years ago, and it happened to come up for renewal right while
> I was in the midst of a cross-country move (yes, there were renewal
> warnings from the place I registered - a significant portion of the
> anger mentioned above is directed at myself), and a poacher grabbed
> it the day it expired and made it a click-through ad site (or whatever
> you call it) - please don't even go there, it probably just encourages
> him to see traffic on it (though to this day I don't really understand
> how it makes him money)
>
> needless to say, several of us tried to convince him to give (or even
> sell) it back to us, but, well, let's just say he was a real piece of
> work
>
> I actually thought I was going to be able to get it back the last
> time it came up for renewal - I was hoping that the traffic had dropped
> off so much that he had decided it was no longer worth it - it got down
> to within days of expiring, then he renewed it - even worse, as I recall
> this time he renewed for 3 years or something
>
> bottom line is that it's gone, and it's my fault
>
> -John Turner
>  Los Alamos National Laboratory
>  Continuum Dynamics Group (CCS-2)
>  Coupled Multiphysics Team Leader (Acting)
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: [Fwd: Re: V4 -final touches]

[John A. T. <tu...@la...>]

Daniel J Sebald wrote:

> Yes, the less "location dependent" the address the better, even if it 
> simply serves as an alias and gets resolved somewhere else.  (Although 
> .info seems unconventional, but big woop.)

that's a long, sad, frustrating story that still angers me every time
I think about it

the short version is that I registered gnuplot.org for the project
several years ago, and it happened to come up for renewal right while
I was in the midst of a cross-country move (yes, there were renewal
warnings from the place I registered - a significant portion of the
anger mentioned above is directed at myself), and a poacher grabbed
it the day it expired and made it a click-through ad site (or whatever
you call it) - please don't even go there, it probably just encourages
him to see traffic on it (though to this day I don't really understand
how it makes him money)

needless to say, several of us tried to convince him to give (or even
sell) it back to us, but, well, let's just say he was a real piece of
work

I actually thought I was going to be able to get it back the last
time it came up for renewal - I was hoping that the traffic had dropped
off so much that he had decided it was no longer worth it - it got down
to within days of expiring, then he renewed it - even worse, as I recall
this time he renewed for 3 years or something

bottom line is that it's gone, and it's my fault

-John Turner
  Los Alamos National Laboratory
  Continuum Dynamics Group (CCS-2)
  Coupled Multiphysics Team Leader (Acting)

Re: More fallout from TBOOLEAN change - hidden3d broken

[Daniel J S. <dan...@ie...>]

Daniel J Sebald wrote:

>
>
>        triangle_classification = ~ (classification[0]
>                 | classification[1]
>                 | classification[2]);
>
>        if (triangle_classification >= 3) { 


No, that is not exactly right.  Technically it should be

        if ((triangle_classification & 3) == 3) {

to be foolproof in general.  However, in this case the above should work, as well as the slightly simplified:

       triangle_classification = classification[0]
                | classification[1]
                | classification[2];
  
       if (!triangle_classification) {

As I said, not exactly reader friendly.

Dan

Re: [Fwd: Re: V4 -final touches]

[Daniel J S. <dan...@ie...>]

Clark Gaylord wrote:

> Daniel J Sebald wrote:
>
>> (Although .info seems unconventional, but big woop.)
>
>
> thereon hangs a tale... 


Dare I ask what that is?

Re: More fallout from TBOOLEAN change - hidden3d broken

[Per P. <per...@ma...>]

On Mar 29, 2004, at 20:46, Ethan Merritt wrote:
> In stepping through the demos to check 3.8k.3 I found
> that something very ugly has happened to hidden3d.
> See "surface2.dem".

Yeah, I noticed that too.

>
> Reverting to the previous version of src/syscfg.h
> made the problem go away, so this was another
> bit of fallout from the TBOOLEAN change.

That change to TBOOLEAN was for the benefit of Mac OS X if I understand 
correctly.

Just so everybody knows what options we have, that change is *not* 
necessary anymore,
with the new aquaterm.trm.
Just to test it, I reverted syscfg.h to v1.26 and it compiles and runs 
on Mac OS X 10.3.2

Having said that, I still think making TBOOLEAN a real boolean is the 
Right Thing to do.

/Per

Re: More fallout from TBOOLEAN change - hidden3d broken

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>Is there a tool (or gcc compile option) that will
>double check for illegal operations on our TBOOLEANs? 
>
>In stepping through the demos to check 3.8k.3 I found
>that something very ugly has happened to hidden3d.
>See "surface2.dem".
>
>Reverting to the previous version of src/syscfg.h
>made the problem go away, so this was another
>bit of fallout from the TBOOLEAN change.
>
>hidden3d.c line 817:
>        casenumber = (plist[new_poly].frontfacing != 0)
>            + 2 * (plist[old_poly].frontfacing != 0);
>
>frontfacing is a TBOOLEAN.
>
>Even worse:
>            TBOOLEAN v1_inside_p, v2_inside_p;
>             unsigned int classification[]
>
>-- 
>            v1_inside_p = ~ (classification[0]
>                             | classification[1]
>                             | classification[2]);
>--
>            v2_inside_p = (v1_inside_p >> 1) & 0x1;
>            v1_inside_p = v1_inside_p & 0x1;
>
>I have corrected the syntax involving frontfacing,
>and changed v?_inside_p to be (unsigned int).
>This fixes surface2.dem, but other problems may lurk.
>

That fixes things and is fine.  However, v1_inside_p and v2_inside_p do 
have the feel of Boolean variables.  The problem is that v1_inside_p is 
used as a temp variable and from a clean C programming viewpoint 
probably shouldn't be.  Also, doing the bit shift on the variable is 
extraneous.  Could have something like:


#define V1_INSIDE_P_BIT 1
#define V2_INSIDE_P_BIT 2

unsigned_int triangle_classification;

        triangle_classification = ~ (classification[0]
                 | classification[1]
                 | classification[2]);

        v1_inside_p = (traingle_classification & V1_INSIDE_P_BIT);
        v2_inside_p = (triangle_classification & V2_INSIDE_P_BIT);

But, if one goes a step further in the code at that point, you'll notice 
that the logic is

        if ((v1_inside_p) && (v2_inside_p)) {

and "v1_inside_p" and "v2_inside_p" aren't used afterward.  So really, 
is it necessary to break this into two individual tests and recombine 
them?  (Future modification perhaps that I'm missing?)   I mean, in the 
definition of "classify()" there is specific use of "1" and "2" rather 
than definitions such as V1_INSIDE_P_BIT AND V2_INSIDE_P_BIT, so if you 
want to be loose about this subroutine and end up with efficient code 
rather than reader friendly code, one could just do:

        triangle_classification = ~ (classification[0]
                 | classification[1]
                 | classification[2]);

        if (triangle_classification >= 3) {

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

Re: [Fwd: Re: V4 -final touches]

[Clark G. <ga...@di...>]

Daniel J Sebald wrote:
> (Although .info seems unconventional, but big woop.)

thereon hangs a tale...

--ckg

Re: [Fwd: Re: V4 -final touches]

[Daniel J S. <dan...@ie...>]

Clark Gaylord wrote:

> -------- Original Message --------
> Subject: Re: V4 -final touches
> Date: Mon, 29 Mar 2004 13:39:51 -0500
> From: Clark Gaylord <ga...@di...>
> To: Petr Mikulik <mi...@ph...>
>
> Petr Mikulik wrote:
>
>>>        The gnuplot FAQ is available from
>>>                http://www.gnuplot.info/faq/
>>>
>>> Maybe the FAQ source should also list
>>>         http://gnuplot.sourceforge.net/faq/index.html
>>
>>
>>
>> No, the FAQ location is OK -- so maybe now it is time to redirect
>> www.gnuplot.info to gnuplot.sf.net
>
>
> I'd be more inclined to get the mirroring right.  If we need to
> establish different mirror than from Lars's, then we should work on
> that.  The sf site was intended for developer use, not end-user use.
>
> --ckg 


Yes, the less "location dependent" the address the better, even if it 
simply serves as an alias and gets resolved somewhere else.  (Although 
.info seems unconventional, but big woop.)

Dan

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

More fallout from TBOOLEAN change - hidden3d broken

[Ethan M. <merritt@u.washington.edu>]

Is there a tool (or gcc compile option) that will
double check for illegal operations on our TBOOLEANs? 

In stepping through the demos to check 3.8k.3 I found
that something very ugly has happened to hidden3d.
See "surface2.dem".

Reverting to the previous version of src/syscfg.h
made the problem go away, so this was another
bit of fallout from the TBOOLEAN change.

hidden3d.c line 817:
        casenumber = (plist[new_poly].frontfacing != 0)
            + 2 * (plist[old_poly].frontfacing != 0);

frontfacing is a TBOOLEAN.

Even worse:
            TBOOLEAN v1_inside_p, v2_inside_p;
             unsigned int classification[]
-- 
            v1_inside_p = ~ (classification[0]
                             | classification[1]
                             | classification[2]);
--
            v2_inside_p = (v1_inside_p >> 1) & 0x1;
            v1_inside_p = v1_inside_p & 0x1;

I have corrected the syntax involving frontfacing,
and changed v?_inside_p to be (unsigned int).
This fixes surface2.dem, but other problems may lurk.

           

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: [Fwd: Re: V4 -final touches]

[Lars H. <lhe...@us...>]

> >No, the FAQ location is OK -- so maybe now it is time to redirect
> >www.gnuplot.info to gnuplot.sf.net
> 
> I'd be more inclined to get the mirroring right.  If we need to
> establish different mirror than from Lars's, then we should work on
> that.  The sf site was intended for developer use, not end-user use.

 And the UCC site was intended as a stop-gap, until someone finds the
 time to set up something better at www.gnuplot.info.

[Fwd: Re: V4 -final touches]

[Clark G. <ga...@di...>]

-------- Original Message --------
Subject: Re: V4 -final touches
Date: Mon, 29 Mar 2004 13:39:51 -0500
From: Clark Gaylord <ga...@di...>
To: Petr Mikulik <mi...@ph...>

Petr Mikulik wrote:
>>        The gnuplot FAQ is available from
>>                http://www.gnuplot.info/faq/
>>
>>Maybe the FAQ source should also list
>>		http://gnuplot.sourceforge.net/faq/index.html
> 
> 
> No, the FAQ location is OK -- so maybe now it is time to redirect
> www.gnuplot.info to gnuplot.sf.net

I'd be more inclined to get the mirroring right.  If we need to
establish different mirror than from Lars's, then we should work on
that.  The sf site was intended for developer use, not end-user use.

--ckg

Re: V4 -final touches

[Petr M. <mi...@ph...>]

>         The gnuplot FAQ is available from
>                 http://www.gnuplot.info/faq/
>
> Maybe the FAQ source should also list
> 		http://gnuplot.sourceforge.net/faq/index.html

No, the FAQ location is OK -- so maybe now it is time to redirect
www.gnuplot.info to gnuplot.sf.net

> Or better yet maybe this should be replaced with a reference to
> 		<http:///sourceforge.net/projects/gnuplot>

This page refers to the newsgroup, thus add reference to
news://comp.graphics.apps.gnuplot

---
PM

Re: V4 -final touches

[BBands <bb...@ya...>]

--- Ethan Merritt <merritt@u.washington.edu> wrote:
> This is the banner message currently printed out by
> 3.8k.3
> 
>         G N U P L O T
>         Version 3.8k patchlevel 3
>         last modified Mon Mar 29 15:17:53 CEST 2004
>         System: Linux 2.4.22-26mdk
> 
>         Copyright(C) 1986 - 1993, 1999 - 2003
>         Thomas Williams, Colin Kelley and many
> others
> 
>         This is a pre-version of gnuplot 4.0. Please
> refer to the documentation
>         for command syntax changes. The old syntax
> will be accepted throughout
>         the 4.0 series, but all save files use the
> new syntax.
> 
>         Type `help` to access the on-line reference
> manual
>         The gnuplot FAQ is available from
>                 http://www.gnuplot.info/faq/
> 
>         Send comments and requests for help to
> <inf...@da...>
>         Send bugs, suggestions and mods to
> <inf...@da...>

On Win2k you also get the following, two lines below
Send... and indented one additional space.

          Send...

           warning: no HOME found

I suspect most win users find that disquieting.

    --jab

=====
John Bollinger, CFA, CMT
www.BollingerBands.com

If you advance far enough, you arrive at the beginning.

__________________________________
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

V4 -final touches

[Ethan M. <merritt@u.washington.edu>]

This is the banner message currently printed out by 3.8k.3

        G N U P L O T
        Version 3.8k patchlevel 3
        last modified Mon Mar 29 15:17:53 CEST 2004
        System: Linux 2.4.22-26mdk

        Copyright(C) 1986 - 1993, 1999 - 2003
        Thomas Williams, Colin Kelley and many others

        This is a pre-version of gnuplot 4.0. Please refer to the documentation
        for command syntax changes. The old syntax will be accepted throughout
        the 4.0 series, but all save files use the new syntax.

        Type `help` to access the on-line reference manual
        The gnuplot FAQ is available from
                http://www.gnuplot.info/faq/

        Send comments and requests for help to <inf...@da...>
        Send bugs, suggestions and mods to <inf...@da...>


Maybe the the copyright should be updated to include 2004?

Maybe the FAQ source should also list
		http://gnuplot.sourceforge.net/faq/index.html

Maybe <inf...@da...> should be updated to
		<gnu...@li...>
Or better yet maybe this should be replaced with a reference to 
		<http:///sourceforge.net/projects/gnuplot>

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195