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

Re: last modified date in CVS

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

Lars Hecking wrote:
>>Anyway: if you're running the CVS version, you're supposed to have a 
>>checked-out copy of the sources around, corresponding to the binary 
>>being used.  And even if you don't, you can still check the RCS $Id 
>>strings embedded in the binary ('ident gnuplot') to find out.
> 
>  
>  I think this (and "strings `which gnuplot` |grep '$Id:'") only works
>  with executables built without optimisation.

Optimization should have little to do with it --- I never build without 
optimization, and ident always worked just fine.

Our source files go quite a bit out of their way to make sure those 
ident strings are hard to optimize out, as a side effect of making them 
acceptable to picky compilers.  Well, at least I don't think I've seen 
any optimizer yet that dared strip those things.

Re: last modified date in CVS

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

> Anyway: if you're running the CVS version, you're supposed to have a 
> checked-out copy of the sources around, corresponding to the binary 
> being used.  And even if you don't, you can still check the RCS $Id 
> strings embedded in the binary ('ident gnuplot') to find out.
 
 I think this (and "strings `which gnuplot` |grep '$Id:'") only works
 with executables built without optimisation.

$ ident `which gnuplot`
/usr/local/bin/gnuplot:
     $Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.36 2005/08/07 09:43:34 mikulik Exp $

Re: last modified date in CVS

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

Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:

>> On the other hand, any discussion of CVS versions older than 'today' 
>> is futile by definition.

> That I don't know about.  It's useful from the developers standpoint for 
> the case where a bug finds its way into CVS.  

Not necessarily.  The primary information needed is: is it *still* 
present in current CVS version?  If not, case closed --- somebody 
already fixed it in the meantime.

If a bug is found in current CVS, and you really need to know when it
got in there (e.g. because you can't figure out what causes it, so you 
need to home in on the change that introduced it), you'll have to run 
explicitly backdated checkouts anyway --- a time stamp in the executable 
doesn't add any new information then.  You know which date you just 
checked out.  But honestly, in all the years we have had a CVS source 
tree, I don't recall having done that more than maybe once or twice.

> Say you're a developer and recognize your copy of gnuplot is a couple
> weeks old by looking on the screen.  So, you update.  You find a bug
> and can report back to the list what day it was last working.

No, you can't --- you can only report when it was still working.  You 
don't know if the _last_ working version was three weeks or three hours 
ago, only that it's less than a couple weeks ago.  To really nail down 
the last working version, you still have to run a series of 'cvs update 
-D <date>' test builds.

Anyway: if you're running the CVS version, you're supposed to have a 
checked-out copy of the sources around, corresponding to the binary 
being used.  And even if you don't, you can still check the RCS $Id 
strings embedded in the binary ('ident gnuplot') to find out.

So to sum it up, the only thing really likely to be achieved by putting 
a CVS update time stamp into the banner printout is to encourage ab-use 
of the CVS version.

Re: last modified date in CVS

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

Hans-Bernhard Broeker wrote:
> Harald Harders wrote:
> 
>> On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote:
> 
> 
>>> Please keep in mind that not all developers are on Unix ...
> 
> 
>> Oh yes, I sometimes forget this. How do these people work?
> 
> 
> With difficulties, needing tools that emulate a Unix environment 
> (Cygwin, DJGPP).  I've been in that position myself for quite a while
> now --- the machine I spend my days sitting in front of runs Win98.
> 
> And there's another gotcha of a client-side approach: not everybody runs 
> 'prepare' all the time.  On Linux, if your tools are recent, you 
> generally can rely on a simple 'make' to get it all right by itself.
> 
>> This sounds good. The big advantage of being able to find out of which
>> date a CVS version is, is comparability.
> 
> 
> On the other hand, any discussion of CVS versions older than 'today' is 
> futile by definition.
>  So we don't need a date stamp on the screen --- 
> we only need to know that the binary is built from current sources. 
> People who can't be bothered to cvs update and re-build before reporting 
> a problem, shouldn't be building from CVS in the first place.


That I don't know about.  It's useful from the developers standpoint for the case where a bug finds its way into CVS.  Say you're a developer and recognize your copy of gnuplot is a couple weeks old by looking on the screen.  So, you update.  You find a bug and can report back to the list what day it was last working.

It may also be useful for referencing against the ChangeLog.

For maintenance personel at universities and labs who might be used to working with bleeding edge releases, that date may be a reminder that gnuplot is long out of date.

Removing the date would still be better, I think, than showing the code was last modified two years ago when it actually was modified two days ago.

Dan

Re: last modified date in CVS

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

Harald Harders wrote:
> On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote:

>>Please keep in mind that not all developers are on Unix ...

> Oh yes, I sometimes forget this. How do these people work?

With difficulties, needing tools that emulate a Unix environment 
(Cygwin, DJGPP).  I've been in that position myself for quite a while
now --- the machine I spend my days sitting in front of runs Win98.

And there's another gotcha of a client-side approach: not everybody runs 
'prepare' all the time.  On Linux, if your tools are recent, you 
generally can rely on a simple 'make' to get it all right by itself.

> This sounds good. The big advantage of being able to find out of which
> date a CVS version is, is comparability.

On the other hand, any discussion of CVS versions older than 'today' is 
futile by definition.  So we don't need a date stamp on the screen --- 
we only need to know that the binary is built from current sources. 
People who can't be bothered to cvs update and re-build before reporting 
a problem, shouldn't be building from CVS in the first place.

If we were to actually care about behaviour of outdated CVS builds, 
having a public CVS becomes a useless exercise.

Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

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

On Tuesday 22 November 2005 12:46 pm, Ga=EBl Varoquaux wrote:
>=20
>     What about adding a terminal flag to choose weather gnuplot should
> do the clipping, or not ? Other terminals would use this flag.

There is one.   TERM_CAN_CLIP
I added it some while ago in an attempt to keep the postscript driver
happy.

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

Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

[V. <gae...@no...>]

    I am forwarding the message I just sent, as it seem to have gotten
lost somewhere :


On Tue, Nov 22, 2005 at 09:20:04PM +0100, Harald Harders wrote:
> > But if we *do* have to special-case post.trm, it's better to
> > just turn off clipping altogether rather than "fix" it
> > by describing an over-large drawing area.
> > Please try the patch I sent you earlier today.

    What about adding a terminal flag to choose weather gnuplot should
do the clipping, or not ? Other terminals would use this flag.

--=20
    Ga=EBl

Re: last modified date in CVS

[Harald H. <h.h...@tu...>]

On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote:

> Harald Harders wrote:
> > grep '/ChangeLog/' CVS/Entries  | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_'
> >
> > during compiling or by ./configure or ./prepare.
>
> Please keep in mind that not all developers are on Unix ...

Oh yes, I sometimes forget this. How do these people work?

> If we want to put a 'last checkin' timestamp into the banner page of
> builds from CVS, the server is the place to implement such a scheme.
> The server would basically modify 'version.h' automatically, every
> single time anybody checks in anything.  The date string could either be
> taken from the RCS $Id, or generated by a script on the server.

This sounds good. The big advantage of being able to find out of which
date a CVS version is, is comparability.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

[Harald H. <h.h...@tu...>]

On Tue, 22 Nov 2005, Ga=EBl Varoquaux wrote:

> On Tue, Nov 22, 2005 at 09:20:04PM +0100, Harald Harders wrote:
> > > But if we *do* have to special-case post.trm, it's better to
> > > just turn off clipping altogether rather than "fix" it
> > > by describing an over-large drawing area.
> > > Please

I got some error opening your mail (Non-hexadecimal character). Was this
everything you have posted?

For postscript, clipping by postscript should be switched of totally. But
it also applies for png, jpg, fig, for example. Thus, clipping stays an
important topic.

Best regards
Harald

--=20
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: last modified date in CVS

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

Hans-Bernhard Broeker wrote:
> Harald Harders wrote:
> 
>> grep '/ChangeLog/' CVS/Entries  | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_'
>>
>> during compiling or by ./configure or ./prepare.
> 
> 
> Please keep in mind that not all developers are on Unix ...
> 
> If we want to put a 'last checkin' timestamp into the banner page of
> builds from CVS, the server is the place to implement such a scheme. The 
> server would basically modify 'version.h' automatically, every single 
> time anybody checks in anything.  The date string could either be taken 
> from the RCS $Id, or generated by a script on the server.

Along the same line of reasoning, I think we wouldn't want to open the door for users or maintainers to easily, unintentionally modifying that date.  In very few instances would that be useful, I think.  Rather it would lead to more confusion where an older CVS version could appear to have a more recent date.  I say we're stamping what's in CVS and if ever someone wants to change that date on a local copy, they have to go out of their way to do it.

Dan

Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

[V. <gae...@no...>]

On Tue, Nov 22, 2005 at 09:20:04PM +0100, Harald Harders wrote:
> > But if we *do* have to special-case post.trm, it's better to
> > just turn off clipping altogether rather than "fix" it
> > by describing an over-large drawing area.
> > Please try the patch I sent you earlier today.

    What about adding a terminal flag to choose weather gnuplot should
do the clipping, or not ? Other terminals would use this flag.

--=20
    Ga=EBl

Re: last modified date in CVS

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

Harald Harders wrote:
> grep '/ChangeLog/' CVS/Entries  | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_'
> 
> during compiling or by ./configure or ./prepare.

Please keep in mind that not all developers are on Unix ...

If we want to put a 'last checkin' timestamp into the banner page of
builds from CVS, the server is the place to implement such a scheme. 
The server would basically modify 'version.h' automatically, every 
single time anybody checks in anything.  The date string could either be 
taken from the RCS $Id, or generated by a script on the server.

Re: last modified date in CVS

[Harald H. <h.h...@tu...>]

On Mon, 21 Nov 2005, Hans-Bernhard Broeker wrote:

> Daniel J Sebald wrote:
>
> > It would be nice if that could be updated via a CVS checkin script or
> > something.  (Not sure if CVS has that capability.)
>
> I'm quite sure that CVS has that capability, but less than convinced
> that it would be a good idea to use it.

Why? I have often missed that information during runtime. Of course, the
most recent checkin is important. And since ChangeLog is changed with
every checkin, the version date of this file could be used. This could be
found out using

grep '/ChangeLog/' CVS/Entries  | sed 's_/ChangeLog/[0-9.]*/\(.*\)//_\1_'

during compiling or by ./configure or ./prepare.

> A better alternative would be not to display the 'last modified' line at
> all, in non-release versions.  Mechanisms for doing that already exist
> to switch between the -beta and the user mailing list addresses.
>
> Or we could exchange the 'last modified' time by a build time, for CVS
> builds.

Of all alternatives, I would prefer to show the CVS timestamp.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: [ gnuplot-Patches-1356114 ] set term post size <foo>in,<baz>in (also cm)

[Harald H. <h.h...@tu...>]

On Thu, 17 Nov 2005, Ethan Merritt wrote:

> > >remember that just because gnuplot thinks the output
> > >resolution is 300 pixels per something, that doesn't
> > >mean the actual display device will have that resolution.
> >
> > This only applies to screen terminals. Screen terminals as
> > x11 should read the system-wide value as default.
>
> There is no such thing as a system-wide default for x11.
> It is different for every display session.
>
> > But for all pixel-based terminals (png, gif, ...), the
> > resolution can be written into the output file.
>
> Actually, it can't.  Or at least, not using libgd.
> That is a failing of libgd but we are stuck with it at present.

If I remember correctly, the developer of libgd has worked together with
the gnuplot developers several times. I we ask him to include resolution
support, he probably will add it in future.

> And I don't see a way to do it for pbm output either.

I do not know the pbm format well enough to say anything about it.

> > - A patch exists that fixes clipping for many (or all?)
> > terminals.
>
> You are referring to patch #1104264?
> That patch does not fix the root problem at all. It just
> multiplies the reported screen limits by a factor large
> enough to let the arrows escape clipping.  This works for
> PostScript because it doesn't really care that you are drawing
> outside of the limits it previously reported.
> On terminals that do care, your patch could make things worse
> rather than better.

No, I am talking about patch #1353539.

The thing is that term->xmax and term->ymax are not what they seem. They
are the internal coordinate values for the position on the screen where
the screen coordinates are 1. In many situations, this position is
identical with the upper right corner of the canvas. But there are also
many situations where this is not the case. For example when using 'set
offset' or 'set size' in postscript, png, jpg, fig (may be more, I have
not tested more).

This test adds "BoundingBox canvas;" to "struct TERMENTRY". By default,
the canvas boundaries and xmax,ymax are identical. They are only changed
when 'set size' or 'set origin' is used in terminals which support a
change of the plot and canvas by this.
It maybe also should rename xmax and ymax to something that fits better
what these variables mean. But I have decided not to touch every file.

Have a look at the newly uploaded patch, compile it with DEBUG defined,
and try out the attached script.
It shows that clipping works correctly for postscript, png, and x11. For
fig, clipping isn't done at all (but the clipping routines are not
invoked. Thus it cannot work with any existing code, but the new code
issues a warning).

> I would much rather the problem, if it is one, be fixed
> by having the terminals correctly report a legal range of
> x and y values.  That would make the current clipping code
> work for all terminals, rather than having to special-case
> terminals that report silly values.

Do you agree that this patch fulfills this? With it, all terminals report
the position of screen 1,1 in term->xmax,term->ymax and the size and
position of the canvas in term->canvas.

> But if we *do* have to special-case post.trm, it's better to
> just turn off clipping altogether rather than "fix" it
> by describing an over-large drawing area.
> Please try the patch I sent you earlier today.

This sounds like a good idea. Does this also apply to libgd? Or does it
produce core dumps when trying to produce a pixel outside of the picture
canvas?

But still terminals as fig have to be able to place labels and arrows
everywhere where other elements of the plots can also appear.

I have had a look to your Postscript clipping patch. I think this could be
useful in addition. I am preparing an extension because Postscript does
not do the clipping by default but can be told to do it.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: last modified date in CVS

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

Hans-Bernhard Broeker wrote:
> Daniel J Sebald wrote:
> 
>> It would be nice if that could be updated via a CVS checkin script or 
>> something.  (Not sure if CVS has that capability.)
> 
> 
> I'm quite sure that CVS has that capability, but less than convinced 
> that it would be a good idea to use it.
> 
> A better alternative would be not to display the 'last modified' line at 
> all, in non-release versions.  Mechanisms for doing that already exist 
> to switch between the -beta and the user mailing list addresses.
> 
> Or we could exchange the 'last modified' time by a build time, for CVS 
> builds.

Either of those would be better than a misleading 'last modified' date.

Dan

Re: Cannot change to 'C:\' (root) on Windows

[Martin H. <mar...@gm...>]

Hans-Bernhard Broeker wrote:
> It's neither --- because that's not what's actually happening. [...]
> You can tell by observing that \' in a single-quoted string
> is interpreted as a ' only if it's the end of the string [...]
Ok, thanks for correcting me - I obviously had misunderstood.

> It works if you think a bit less Windows-ish.  Write c:/
> instead of c:\, or cd 'c:/' [...]
Agreed.

Please allow me to bug you again with my second post: There I mentioned
to to intercept the return value of Win32 dialogs (such as "Folder
Select", "Open File"...) and replace all backslashes there with forward
slashes. Correct me, if I'm wrong but I believe the dialogs always
return backslashed path's. Thus the path would be compatible with what
you said above in the first place. So maybe such conversion under
Windows make things easier - I mean, generally... (not pushing anything
here)?!

Of course the parsing issue remains. I am aware that fixing this would
automatically fix the problem from above... but eventually it helps on
second thoughts...?!

.....and if there is a reason not to do so then I would also be
intereseted in. Thanks.

With regards,

Martin Halle.

Re: last modified date in CVS

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

Daniel J Sebald wrote:

> It would be nice if that could be updated via a CVS checkin script or 
> something.  (Not sure if CVS has that capability.)

I'm quite sure that CVS has that capability, but less than convinced 
that it would be a good idea to use it.

A better alternative would be not to display the 'last modified' line at 
all, in non-release versions.  Mechanisms for doing that already exist 
to switch between the -beta and the user mailing list addresses.

Or we could exchange the 'last modified' time by a build time, for CVS 
builds.

Re: pm3d question

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

Johannes Zellner wrote:

> It think the correct depth ordering for pm3d should be the default,
> since it is not really time consuming and it will most likely produce
> correct plots. The other pm3d methods (scans...) will produce likely
> incorrect plots (depending on your data for example).

Not really.  In what I expect to be the most frequent data patterns for 
pm3d plots (regular, x-y aligned grids of data), point-like 
depth-sorting will typically produce worse results than the currently 
existing output patterns.   Scansbackward and Scansforward are not bad 
at all, for this kind of data.  One of them will be exactly correct.

To sum it up a little aggressively: z-sorting, scansbackward and 
scansforward are all about equally wrong, but are also each necessary to 
get a correct display in *some* case.

Re: pm3d question

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

Ethan A Merritt wrote:
> OK. Yes, I see the same difference in speed with isosamples set to 40.  
> Although you can get a factor of roughly 4X back again by enabling 
> HIDDEN3D_QUADTREE.

At high isosamples settings, you should absolutely use that switch.
I've even been thinking about enabling it by default.

> This will not magically do the full, correct, tests for
> which quadrangles to clip. But it *will* mean that other objects
> (labels, points, vectors) will be correctly obscured by the 
> Z-sorted quadrangles, and vice versa. 

I'm reasonably sure it doesn't mean just that.  It actually means means 
that all the problems inherent in treating polygons as sortable points 
will be inflicted on the hidden3d code's output.

If you want other objects hidden-surface removed by the pm3d polygons, 
you can just feed those polygons to the hidden3d engine as they are, but 
flagged as invisible (like with the 'trianglepattern 0' option of 'set 
hidden3d').

The only real alternative would be to a full-featured, object-precision 
3D rendering engine to replace both pm3d (polygons) and hidden3d 
(wireframe) output.  Such a beast would probably be even slower than 
hidden3d already is.

Re: Cannot change to 'C:\' (root) on Windows

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

Martin Halle wrote:

> I don't know whether it's right or wrong to interprete \' as ' or really
> \'. 

It's neither --- because that's not what's actually happening.  You can 
tell by observing that \' in a single-quoted string is interpreted as a 
' only if it's the end of the string (and the command line).  There are 
problem with the parsing of '' strings, but backslash quoting is not one 
of them.


> would entirely leave this decision up to you. But: To change to a
> root folder on Windows if one uses the "Select Folder" dialog is not
> working. 

It works if you think a bit less Windows-ish.  Write c:/ instead of c:\, or

	cd 'c:/'

directly in the command line, and everything just works.

> So my suggestion is as follows: Why not intercepting at least the return
> value of the "Select Folder" dialog to provide the "cd" command with a
> valid path. 

Because that's the wrong place to fix it.

Re: pm3d question

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

On Sunday 20 November 2005 11:41 am, Johannes Zellner wrote:
>
> The comparison depends pretty much on the sampling rate. Try to run the
> attached versions w/o ~/.gnuplot. (set sam 40; set iso 40). On my
> machine the pm3d correctly ordered plots (tori.gpi) run approx.
> 4 times faster than the hidden3d version (tori_hl.gpi).

OK. Yes, I see the same difference in speed with isosamples set to 40.  
Although you can get a factor of roughly 4X back again by enabling 
HIDDEN3D_QUADTREE.

> it is really time consuming to do the correct hidden3d calculations.
> It think sorting the pm3d quadrangles and the hidden3d code are two very
> different approches: the hidden3d code has to calculate intersections of
> surfaces for example and doesn't draw hidden line segments at all. The
> pm3d code on the other hand draws all quadrangles: by sorting the
> quadrangles those lying in front overwrite those drawn before.
> It think the correct depth ordering for pm3d should be the default,

I agree with all of that.
My question still remains, though:

Why not move the Z-sorting of quadrangles into the hidden3d code?

This will not magically do the full, correct, tests for
which quadrangles to clip. But it *will* mean that other objects
(labels, points, vectors) will be correctly obscured by the 
Z-sorted quadrangles, and vice versa. 


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: pm3d question

[Johannes Z. <joh...@ze...>]

On Sun, Nov 20, 2005 at 08:41:18PM +0100, Johannes Zellner wrote:
> On Sun, Nov 20, 2005 at 10:58:48AM -0800, Ethan A Merritt wrote:
> [...]
> > Have you figured out any reason why the "set hidden3d" 
> > apparently runs much slower on your machines than on mine?
> 
> The comparison depends pretty much on the sampling rate. Try to run the
> attached versions w/o ~/.gnuplot. (set sam 40; set iso 40). On my

sorry, here are the attached test cases.

-- 
Johannes

Re: pm3d question

[Johannes Z. <joh...@ze...>]

On Sun, Nov 20, 2005 at 10:58:48AM -0800, Ethan A Merritt wrote:
[...]
> Have you figured out any reason why the "set hidden3d" 
> apparently runs much slower on your machines than on mine?

The comparison depends pretty much on the sampling rate. Try to run the
attached versions w/o ~/.gnuplot. (set sam 40; set iso 40). On my
machine the pm3d correctly ordered plots (tori.gpi) run approx.
4 times faster than the hidden3d version (tori_hl.gpi).

> If there really is a speed bottleneck in the code, I'd like
> to try to pin it down and fix it.  Then we can go back to
> discussing if there are any other drawbacks to merging your
> pm3d sort code with the general hidden3d capability.

I believe that this is not a "bottleneck" but it is more the fact that
it is really time consuming to do the correct hidden3d calculations.
It think sorting the pm3d quadrangles and the hidden3d code are two very
different approches: the hidden3d code has to calculate intersections of
surfaces for example and doesn't draw hidden line segments at all. The
pm3d code on the other hand draws all quadrangles: by sorting the
quadrangles those lying in front overwrite those drawn before.
It think the correct depth ordering for pm3d should be the default,
since it is not really time consuming and it will most likely produce
correct plots. The other pm3d methods (scans...) will produce likely
incorrect plots (depending on your data for example).

-- 
Johannes

Re: pm3d question

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

On Sunday 20 November 2005 07:22 am, Johannes Zellner wrote:
> On Sat, Nov 19, 2005 at 07:18:55PM -0800, Ethan A Merritt wrote:
> > Can anyone explain to me why the two surfaces produced
> > by the command below are colored so differently?
> >
> >   splot x with pm3d, y with pm3d
>
> btw.: did you see the usefulness of the "set pm3d depth" patch with
> such intersecting surfaces?

That was, in fact, why I drew this plot in the first place.
I was trying to determine if there were any artifacts near the
line of intersection, but I got distracted by the coloring
glitch.

Have you figured out any reason why the "set hidden3d" 
apparently runs much slower on your machines than on mine?
If there really is a speed bottleneck in the code, I'd like
to try to pin it down and fix it.  Then we can go back to
discussing if there are any other drawbacks to merging your
pm3d sort code with the general hidden3d capability.

I hope the following conceptual example makes it clear why
I think this would be useful:

f(x,y) = theory1_prediction(x,y)
g(x,y) = theory2_prediction(x,y)

set hidden3d
splot f(x,y) with pm3d, g(x,y) with pm3d, \
      "experiment" using 1:2:3 with points pointsize 3 pt 6


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: pm3d question

[Johannes Z. <joh...@ze...>]

On Sat, Nov 19, 2005 at 07:18:55PM -0800, Ethan A Merritt wrote:
> Can anyone explain to me why the two surfaces produced
> by the command below are colored so differently?
> 
>   splot x with pm3d, y with pm3d
> 
> The "y" surface is colored smoothly, but the "x"
> surface is colored in 9 increments only.
> What command would I use to get two smoothly
> colored surfaces?

btw.: did you see the usefulness of the "set pm3d depth" patch with
such intersecting surfaces?

-- 
Johannes