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

zooming of inline data

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

I thought that Ethan has already committed his patch
    [ 1723715 ] Refresh plot or zoom without re-reading data
and that it was released in 4.2.1, but it is not the case.
What was the reason of not putting it into cvs (see 2007-07-01 04:36)?


There is also this patch
    [ 1745865 ] store raw data to refresh plot without rereading files
which is somehow similar in results (but caches all datafiles).


So, how to continue? Zooming of inline data is really important (and not 
only for Octave users).

---
PM

Re: how to plot random data of large range

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

On Monday 20 August 2007, raja ram wrote:
> Hi,
>   I wish to have a 2D plot, such that the X-axis having only 15 points but
> it ranges from 1:500. The problem is gnu plot automatically scales the x
> axis according to the range of x axis data, as the x axis data vary by
> large range, so the final data are very close to each other. What I want is
> that Gnu plot just read the data and just plot it by marking it at a
> suitable distance i.e. just like reading a text data in column and placing
> it on x-axis and ploting the corresponding value.

 plot 'data' using 0:xticlabels(1):2

-- 
Ethan Merritt
(on the road)

Re: [Fwd: GNUPLOT: 'set timestamp' error - 2]

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

On Friday 17 August 2007 04:58, Hans-Bernhard Br=F6ker wrote:
> Hello, guys,
>=20
> forwarding this from -bugs, which doesn't appear to be read much.
>=20
> There's a parser bug in "set timestamp".  The <xoff> argument to=20
> "offset" fails to be optional.  It's still present in current CVS, AFAICS.

The parser for "set timestamp" was upgraded on 2005-07-27 from
the old version 3.7 fixed-order option syntax to the newer
options-in-any-order syntax of version 4.  As with all(?) other set
commands, the "offset" keyword is now parsed by the shared routine
get_position_default().

But the documentation was not updated to match.
=46ixed in CVS for 4.2.1 and 4.3


=20
> See original report for the details:
>=20
> -------- Original Message --------
> Subject: GNUPLOT: 'set timestamp'  error - 2
> Date: Tue, 14 Aug 2007 23:22:15 -0400
> From: Victor J. Slabinski <sla...@pa...>
> To: HBB...@t-..., Har...@ge...
> CC: USNO Office <sla...@us...>,=20
> gnu...@li..., gnu...@li...
>=20
> Hans,
>=20
>       Thank you for your reply and explanation that
> 1) gnuplot 4.2 specifies that the keyword 'offset' should be included
>     with the timestamp offset parameters, and that
> 2) I should use the version 4.2 manual with gnuplot 4.2 .
>     I have now downloaded that manual from http://www.gnuplot.info/:
> .        "gnuplot, An Interactive Plotting Program"
> .        version 4.2, manual prepared by Dick Crawford
> .        3 March 2007 .
>=20
>       I have tried using the set command you suggest:
>=20
>       set timestamp rotate offset  ,4                              (5)
>=20
> This command fits the command syntax specified on page 128, sec. 43.67
> "Timestamp" in the above referenced manual:
>=20
>       set timestamp ... {rotate} {offset {<xoff>} {,<yoff>}}    .  (6)
>=20
> BUG REPORT
>=20
>       But when I use your command with the 'offset' keyword, I still
> get the error message
>=20
> .    set timestamp rotate offset  ,4
> .                                 ^
> ."plotorb", line 4: invalid expression
>=20
> just like before.  This occurs using
> .                  GNUPLOT Version 4.2 patchlevel 0
> .                  last modified March 2007
> .                  System: Linux 2.6.20-1.2952.fc6
> [Changing to 'set timestamp rotate offset 0,4' cures the problem.]
>=20
> CONCLUSION
>=20
>       The above reported timestamp error is either
> a) a bug in gnuplot 4.2 or
> b) a typo in the version 4.2 manual, p.128, sec. 43.67 "Timestamp".
>     The syntax should read
>=20
>       set timestamp ... {offset {<xoff>{,<yoff>}}}                 (7)
>=20
> This syntax is slightly different from the syntax expression (6) above.
>=20
>       Thank you for your help on this matter.  I am not subscribed to
> the list.
>=20
> Victor J. Slabinski
>=20
> ***********************************************************************
> Hans-Bernhard Broker wrote:                  2007 August 10
>=20
> > Victor J. Slabinski wrote:
> > 		   set timestamp rotate   ,4                      (2)
> >=20
> > (which assumes the default xoff=3D0) may give an error message.
>=20
> As of 4.2, it will.  The syntax in version 4.2 uses keywords in several
> places where implicit ordering of command line elements was used so far.
>    The equivalent command according to the manual for version 4.2 would b=
e:
>=20
> 	set timestamp rotate offset  ,4
>=20
> >       The timestamp error I report here is either
> > a) a bug in gnuplot 4.2 or
> > b) a typo in the gnuplot manual:
> > .   "gnuplot, An Interactive Plotting Program"
> > .   manual prepared by Dick Crawford
> > .   Last editted: 2004/04/13 17:23:36 .
>=20
> It's actually neither, because you appear to be looking at an outdated
> version of the manual.  The version 4.0 manual doesn't apply to version 4=
=2E2.
> EOF
>=20
>=20
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>=20

=2D-=20
Ethan A Merritt            Courier Deliveries: 1959 NE Pacific
Dept of Biochemistry
Health Sciences Building
University of Washington - Seattle WA 98195-7742

[Fwd: GNUPLOT: 'set timestamp' error - 2]

[<HBB...@t-...>]

Hello, guys,

forwarding this from -bugs, which doesn't appear to be read much.

There's a parser bug in "set timestamp".  The <xoff> argument to 
"offset" fails to be optional.  It's still present in current CVS, AFAICS.

See original report for the details:

-------- Original Message --------
Subject: GNUPLOT: 'set timestamp'  error - 2
Date: Tue, 14 Aug 2007 23:22:15 -0400
From: Victor J. Slabinski <sla...@pa...>
To: HBB...@t-..., Har...@ge...
CC: USNO Office <sla...@us...>, 
gnu...@li..., gnu...@li...

Hans,

      Thank you for your reply and explanation that
1) gnuplot 4.2 specifies that the keyword 'offset' should be included
    with the timestamp offset parameters, and that
2) I should use the version 4.2 manual with gnuplot 4.2 .
    I have now downloaded that manual from http://www.gnuplot.info/:
.        "gnuplot, An Interactive Plotting Program"
.        version 4.2, manual prepared by Dick Crawford
.        3 March 2007 .

      I have tried using the set command you suggest:

      set timestamp rotate offset  ,4                              (5)

This command fits the command syntax specified on page 128, sec. 43.67
"Timestamp" in the above referenced manual:

      set timestamp ... {rotate} {offset {<xoff>} {,<yoff>}}    .  (6)

BUG REPORT

      But when I use your command with the 'offset' keyword, I still
get the error message

.    set timestamp rotate offset  ,4
.                                 ^
."plotorb", line 4: invalid expression

just like before.  This occurs using
.                  GNUPLOT Version 4.2 patchlevel 0
.                  last modified March 2007
.                  System: Linux 2.6.20-1.2952.fc6
[Changing to 'set timestamp rotate offset 0,4' cures the problem.]

CONCLUSION

      The above reported timestamp error is either
a) a bug in gnuplot 4.2 or
b) a typo in the version 4.2 manual, p.128, sec. 43.67 "Timestamp".
    The syntax should read

      set timestamp ... {offset {<xoff>{,<yoff>}}}                 (7)

This syntax is slightly different from the syntax expression (6) above.

      Thank you for your help on this matter.  I am not subscribed to
the list.

Victor J. Slabinski

***********************************************************************
Hans-Bernhard Broker wrote:                  2007 August 10

> Victor J. Slabinski wrote:
> 		   set timestamp rotate   ,4                      (2)
> 
> (which assumes the default xoff=0) may give an error message.

As of 4.2, it will.  The syntax in version 4.2 uses keywords in several
places where implicit ordering of command line elements was used so far.
   The equivalent command according to the manual for version 4.2 would be:

	set timestamp rotate offset  ,4

>       The timestamp error I report here is either
> a) a bug in gnuplot 4.2 or
> b) a typo in the gnuplot manual:
> .   "gnuplot, An Interactive Plotting Program"
> .   manual prepared by Dick Crawford
> .   Last editted: 2004/04/13 17:23:36 .

It's actually neither, because you appear to be looking at an outdated
version of the manual.  The version 4.0 manual doesn't apply to version 4.2.
EOF

Suggestion for FAQ

[Albrecht G. <alb...@tu...>]

Hello,

first of all thank you very, very much for maintaining Gnuplot which is 
by far the best data-visualization package I know!

I think it would be useful to add the following to your FAQ:

Q: How can I insert the euro sign  when using the postscript-terminal
A: Send ' set encoding iso_8859_15 ' to gnuplot.  After that the 
euro-sign can be accessed with character code 244 on the postscript 
enhanced terminal.

Thanks,

    Albrecht



-- 
Dipl.-Vw. Albrecht Gradmann, M.A.
Institut für Wirtschaftswissenschaft
Abteilung für Volkswirtschaftslehre
Julius-Albert-Straße 2
38678 Clausthal-Zellerfeld
Telefon: +49 (5323) 72 - 7626
Fax: +49 (5323) 72 - 7639

Re: Assignment functions (patchset # 1774478)

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

On Thursday 16 August 2007 05:10, Hans-Bernhard Br=F6ker wrote:
>=20
> Maybe, instead of inventing more new syntax, we should follow=20
> established C syntax

That was the original intent. But I was insufficiently clever at the time;
I could not see how to modify gnuplot's parsing routines to handle the
assignment operator.  Now I have stared at the code more intently.

I have updated the patch on SourceForge to implement C-like assignment
syntax.  For example,
gnuplot> show at a =3D b =3D c =3D 1
        pushc "a"
        pushc "b"
        pushc "c"
        pushc 1
        =3D
        =3D
        =3D

This addition to the expression syntax allows the running sum trick
without any special handling of data column processing:

   plot 'foo' using 1:(sum =3D sum + $2)

> implement the comma operator and the "each assignment is an expression, t=
oo"
> idea.  E.g. an averaging filter could be expressed as:
>=20
> 	using 1:(N =3D N + 1, sum =3D sum + $2, sum / N)

Adding the comma operator would be relatively easy, I think.

> And even if we're going to do this, the using specification is not=20
> really the right place to do it in.

I entirely agree.  The patches I posted were equivalent to=20
"thinking out loud".  I didn't like either of the initial two
implementations. But I find it very useful to have a version that runs
and that approximates the desired functionality so that I can
experiment with what the new feature allows or doesn't allow.=20

Anyhow, the version now on SourceForge is the first to truly capture
the original intent.  It adds '=3D' as an assignment operator; all else
follows automatically from that.

It needs to be double-checked for operator precedence, possible
memory leaks, etc.  But it is usable for testing as-is.

=2D-=20
Ethan A Merritt

Re: Assignment functions (patchset # 1774478)

[<pl...@pi...>]

On Thu, 16 Aug 2007 14:10:10 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> Ethan A Merritt wrote:
>> On Wednesday 15 August 2007 00:40, plotter wrote:
>
>> The space required to write it out once should be about the same either  
>> way.
>> But yes, I can see that the earlier f(x)=assign("var",expression)
>> makes it much easier to re-use the definition concisely in multiple plot
>> commands.
>
> Maybe, instead of inventing more new syntax, we should follow
> established C syntax a little further, e.g. implement the comma operator
> and the "each assignment is an expression, too" idea.  E.g. an averaging
> filter could be expressed as:
>
> 	using 1:(N = N + 1, sum = sum + $2, sum / N)
>
> or even
>
> 	using 1:((sum += $2)/++n)

That I like, I think the assign() idea was done as a quick and easy way to  
slip this into the existing parser. It served well to prove the principal  
but yields a rather clumbsy syntax.

I would like to see this sort of "each assignment is an expression"  
approach, that was in fact my original request which Ethan rapidly  
provided in what is now called the "old" implementation.

I think it is useful that whatever is done can be done within a function  
call or similar mechanism that allows pulling the detail outside of the  
plot command itself.


>
>> It would be very easy to move the assignment evaluation to the beginning
>> of the per-line processing rather than the end.  But then it becomes a
>> problem what to do if the data line turns out to have missing or invalid
>> entries. The earlier variant already suffers from this (see below).
>> I'm open to suggestions here.
>
> Honestly, I think this whole idea is going in the wrong direction.
> We're straying awfully far from the "one tool <--> one task" approch of
> Unix tradition here.  gnuplot is a plotting program, not a substitute
> for awk, Perl or Excel.  I'd prefer it if we left generic data
> processing to generic tools designed for the job.

I see your point and I dont think gnuplot needs to provide these sort of  
data processing tools itself. The whole thing here is just to provide a  
mechanism not to start providing any data processing functions directly.  
This would be going beyond "one tool <--> one task" .

Adding a means to hook in simple algebraic tasks written by the user is  
more analogous to calling an awk script from gnuplot except that it is  
tightly bound to the plot iteration rather than duplicating that  
externally.

My area under graph example could be done externally but I can do the same  
thing with gnuplot for the price of two local variables and one (longish)  
line added to my gnu file.

I would not wish to do complex data processing this way but for simple  
tasks like a.u.g. , mean/min/max values it makes a lot of sense.


>
> And even if we're going to do this, the using specification is not
> really the right place to do it in.  It should be moved to a separate
> command.
>

Your comment agrees with my wish to see a mechanism outside the plot line  
rather than burgeoning the using spec, though I would like to see this as  
a hook into the existing plot iteration of the data.

If this were done as a separte command it would end up having to duplicate  
much of what plot does. That duplication of code could lead to errors.

I think my preference would be , as you suggest, "each assignment is an  
expression" and comma syntax but inside the existing function call. This  
would avoid the rather awkward assign() .

Thanks for you comments, Peter.

Re: Possible FAQ

[<HBB...@t-...>]

Christian Ihle wrote:

> I've been looking for a way of overlaying a vector field upon a pm3d 
> surface with no success so far. This is similar than putting contours 
> over a surface with the difference that it seems I can't use splot to 
> draw vectors, 

You either haven't read "help vectors" lately, or you're using an 
out-of-date version.  gnuplot 4.2 supports splot with vectors.

Re: Assignment functions (patchset # 1774478)

[<HBB...@t-...>]

Ethan A Merritt wrote:
> On Wednesday 15 August 2007 00:40, plotter wrote:

> The space required to write it out once should be about the same either way.
> But yes, I can see that the earlier f(x)=assign("var",expression)
> makes it much easier to re-use the definition concisely in multiple plot
> commands. 

Maybe, instead of inventing more new syntax, we should follow 
established C syntax a little further, e.g. implement the comma operator 
and the "each assignment is an expression, too" idea.  E.g. an averaging 
filter could be expressed as:

	using 1:(N = N + 1, sum = sum + $2, sum / N)

or even

	using 1:((sum += $2)/++n)

> It would be very easy to move the assignment evaluation to the beginning
> of the per-line processing rather than the end.  But then it becomes a
> problem what to do if the data line turns out to have missing or invalid
> entries. The earlier variant already suffers from this (see below).
> I'm open to suggestions here.

Honestly, I think this whole idea is going in the wrong direction. 
We're straying awfully far from the "one tool <--> one task" approch of 
Unix tradition here.  gnuplot is a plotting program, not a substitute 
for awk, Perl or Excel.  I'd prefer it if we left generic data 
processing to generic tools designed for the job.

And even if we're going to do this, the using specification is not 
really the right place to do it in.  It should be moved to a separate 
command.

Re: Polishing the new PDF terminal (cairopdf)

[<tim...@en...>]

Ethan Merritt wrote:
> I'd like to collect comments and suggestions on any rough edges
> marring the new cairopdf terminal driver.
>
> I know of 3 problems, 2 of which are illustrated by 
> fillbetween.dem
>
> 1) The pattern fill scales as a bitmap rather than as
>    a vector pattern.  This is ugly at high resolution.
>    If we can't make the vector pattern scale correctly,
>    then in monochrome mode we should probably replace
>    the pattern fill with incremental solid shading.
>    pattern 1 = no fill
>    pattern 2 = black
>    pattern 3 = 50% grey
>    etc
>
> 2) The fill area is not clipped to the plot boundaries.
>    This puzzles me, because I thought that the clipping
>    was done by the core code.  But other terminals do not
>    show this, so...
>
> The 3rd problem may or may not be a gnuplot bug.
>
> 3) Under some conditions the entire plot has a black background.
>    I only see this on machines with very different versions of
>    cairo/pango/kde/kpdf/... so I'm having difficulty figuring
>    out which program or library  is at fault.  But even if it is
>    a viewer bug, there may still be a fix to gnuplot that would
>    avoid triggering it
>
> Missing features:
>
> 4) There should be a dashlength option (similar to postscript)
>
> 5) Circles (e.g. point types 6 and 7) look jagged.
>    This is ultimately the fault of the cairo library, but perhaps
>    we could work around it by scaling a well-hinted character
>    glyph instead?
>
> Any other observations?
>
>   
Hi Ethan,

I am back to a usual internet connection, I'll try to provide some 
answers to your questions.

1) This is a limitation in pdf support in current cairo. Some operations 
are not fully implemented and so bitmap fallbacks are used instead. 
Adrian Johnson is working on it, and his cairo repository is available 
here: 
http://gitweb.freedesktop.org/?p=users/ajohnson/cairo.git;a=summary 
(branch pdf-meta-surface-pattern)

With it, the patterns are vectorized. However, this currently shows 
another problem: pattern tiles have seams between each other, so it's 
not so great. I am sure this will be worked out in the future.

2) I cannot reproduce this. For me, the fill area is properly clipped.

3) Again, I don't remember having seen this.

4) I saw that you implemented it. Maybe some more text in the doc would 
be interesting... and the same implementation in wxt ;) In general I 
think it would be good to keep the two terminals very close to each 
other so that testing is easier.

5) I don't see this. For me, those circles are perfect. Instead of 
blaming cairo, I would blame the pdf renderer, which may or may not do 
some antialiasing. I am using evince 0.8.3 with poppler 0.5.9. kpdf 
0.5.7 (kde 3.5.7) gives nice circles too.


As for my personal observations, I am worried by one thing really: the 
bitmap fallbacks for the pm3d polygons. This is due to the composition 
operator I am using in the cairo code to draw the polygons. With the 
default operator (CAIRO_OPERATOR_OVER), the polygons show seams between 
them, even though their coordinates are contiguous. This is also what 
happens for the current svg (non-cairo) terminal, for aquaterm, and 
maybe others. To workaround that, I am using CAIRO_OPERATOR_SATURATE and 
draw the polygons front to back. This gives in wxt a nice seamless pm3d 
surface. But for the cairopdf terminal, it results in a bitmap fallback, 
as you see currently with the patterns. So my question is the following: 
do we want a seamless but bitmapped pm3d surface (until 
CAIRO_OPERATOR_SATURATE is implemented in cairo pdf backend) or a 
vectorized pm3d surface, but with seams between the polygons ?

Best regards,

Timothée

Re: Assignment functions (patchset # 1774478)

[<pl...@pi...>]

On Wed, 15 Aug 2007 18:02:45 +0200, Ethan A Merritt  =

<merritt@u.washington.edu> wrote:

> On Wednesday 15 August 2007 00:40, plotter wrote:
>> >  Example:
>> >       SUM =3D 0
>> >       plot 'foo' using 1:(f($2)):assign(SUM =3D SUM + $2):assign(N =
=3D $0)
>> >       print "Sum of y values is ",SUM
>> >       print "Mean y value is ", SUM/N
>> >
>> However I see a couple of disadvantages with this approach of doing t=
his
>> in 'using' clause of plot.
>>
>> Firstly plot lines can get very long and cumbersome already, especial=
ly  =

>> by
>> the time one has added linetype title and colour specifiers. Already =
 =

>> some
>> of the uses I have for assign run to several lines on their own. I th=
ink
>> anything more than your simple example would make plot lines very har=
d  =

>> to
>> follow.
>
> The space required to write it out once should be about the same eithe=
r  =

> way.
> But yes, I can see that the earlier f(x)=3Dassign("var",expression)
> makes it much easier to re-use the definition concisely in multiple pl=
ot
> commands.
>
> I will have to think about whether there is a way to tweak the
> assign(var =3D expression)  variant so that you can be equally concise=
.

The big difference is the function is outside the plot command so all th=
at  =

is added is f($2) or a meaningful name like run_mean($2) that actually  =

make the plot command more readable and takes all the messy detail  =

elsewhere.


>
>> Second this is post processing. Much of the usefullness of this  =

>> technique
>> comes from the way I used it in a funtion that returns a value to usi=
ng
>> that gets plotted directly. The post processing seems to be a bit of =
a
>> show stopper for the way I was using this.
>
> It would be very easy to move the assignment evaluation to the beginni=
ng
> of the per-line processing rather than the end.  But then it becomes a=

> problem what to do if the data line turns out to have missing or inval=
id
> entries. The earlier variant already suffers from this (see below).
> I'm open to suggestions here.
>
> However, I'm not sure that the post/pre processing choice makes any
> fundamental difference in what you can plot.  The two variants below  =

> should
> achieve the same result, right?
>
>  old:  plot "foo" using 1:(assign("SUM",SUM+$2)) title 'running sum'
>
>  new:  plot "foo" using 1:(SUM+$2):assign(SUM=3DSUM+$2) title 'running=
 sum'
>
>

yes these two are equivalent because you've duplicated the code. If it w=
as  =

less trivial the whole thing would need duplicating and if the code  =

changed some other variables as in my examples this repetition would mes=
s  =

things up badly.

IMHO half the benefit of the old form was being able to operate on the  =

data and pass back a value to be plotted.

>
> One more thing:
> The behaviour of the earlier form is poorly-defined in a case like thi=
s
>
>    A(x) =3D assign("VAR_A", f(VAR_A))
>    B(x) =3D assign("VAR_B", VAR_A + VAR_B)
>    plot "foo" using 1:(A($2)):(B($3))
>
> OK, you can say "don't do that".  The point is that I don't think the =
 =

> order
> of evaluation is guaranteed.  Furthermore, what happens if column 3  =

> contains
> a '?' (missing data) or 'NaN' (illegal value).  Does the value of A ge=
t
> updated or not?  What about the value of B?  If so, with what value?
> Don't we have a problem that A and B can get out of sync?
>

That's true , although I dont think it's unsurmountable as long a functi=
on  =

can return NAN. The behaviour of
plot is defined in these circumstances and this sort of advanced user  =

technique carries a responsability of testing data before assigning and =
 =

conforming to plot behaviour.

I'd just started playing with NaN which is why I marked my running_mean =
 =

example as unfinished. This is something to look at but I dont think it'=
s  =

a problem, at least in the old format where preprocessing allows a means=
  =

to kick out. Returning NaN would be like raising an exception on that da=
ta  =

point. Things can be kept in sync.

Good point though.

You could check up on execution order. If that is not defined that could=
  =

be tricky , it may be necessary to force the order if plot contains  =

functions.

So far I have not tried a situation where this sort of dependancy comes =
in.


>
> I'm cc'ing this to the developer's mailing list.  Maybe useful  =

> suggestions
> will come in from a new direction.
>
> 	Ethan

Sorry, I did not realise I had mailed that last two comments to you only=
.  =

The reply policy of mailman lists is a contant cause of confusion. Since=
 I  =

am on several I often mix up who does what. I'll try to remember I shoul=
d  =

not use "reply" on gnuplot-beta.

thx.

Re: Assignment functions (patchset # 1774478)

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

On Wednesday 15 August 2007 00:40, plotter wrote:
> >  Example:
> >       SUM = 0
> >       plot 'foo' using 1:(f($2)):assign(SUM = SUM + $2):assign(N = $0)
> >       print "Sum of y values is ",SUM
> >       print "Mean y value is ", SUM/N
> >
> However I see a couple of disadvantages with this approach of doing this  
> in 'using' clause of plot.
> 
> Firstly plot lines can get very long and cumbersome already, especially by  
> the time one has added linetype title and colour specifiers. Already some  
> of the uses I have for assign run to several lines on their own. I think  
> anything more than your simple example would make plot lines very hard to  
> follow.

The space required to write it out once should be about the same either way.
But yes, I can see that the earlier f(x)=assign("var",expression)
makes it much easier to re-use the definition concisely in multiple plot
commands. 

I will have to think about whether there is a way to tweak the
assign(var = expression)  variant so that you can be equally concise.
 
> Second this is post processing. Much of the usefullness of this technique  
> comes from the way I used it in a funtion that returns a value to using  
> that gets plotted directly. The post processing seems to be a bit of a
> show stopper for the way I was using this.

It would be very easy to move the assignment evaluation to the beginning
of the per-line processing rather than the end.  But then it becomes a
problem what to do if the data line turns out to have missing or invalid
entries. The earlier variant already suffers from this (see below).
I'm open to suggestions here.

However, I'm not sure that the post/pre processing choice makes any
fundamental difference in what you can plot.  The two variants below should
achieve the same result, right?

 old:  plot "foo" using 1:(assign("SUM",SUM+$2)) title 'running sum'

 new:  plot "foo" using 1:(SUM+$2):assign(SUM=SUM+$2) title 'running sum'



One more thing: 
The behaviour of the earlier form is poorly-defined in a case like this

   A(x) = assign("VAR_A", f(VAR_A))
   B(x) = assign("VAR_B", VAR_A + VAR_B)
   plot "foo" using 1:(A($2)):(B($3))

OK, you can say "don't do that".  The point is that I don't think the order
of evaluation is guaranteed.  Furthermore, what happens if column 3 contains
a '?' (missing data) or 'NaN' (illegal value).  Does the value of A get
updated or not?  What about the value of B?  If so, with what value?
Don't we have a problem that A and B can get out of sync? 


I'm cc'ing this to the developer's mailing list.  Maybe useful suggestions
will come in from a new direction.

	Ethan
-- 
Ethan A Merritt

Possible FAQ

[Christian I. <ci...@in...>]

Hi,

I've been looking for a way of overlaying a vector field upon a pm3d 
surface with no success so far. This is similar than putting contours 
over a surface with the difference that it seems I can't use splot to 
draw vectors, but only plot with proper options.

Thanks a lot for your help,

Christian

Re: problem with gnuplot 4.3

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

On Monday 13 August 2007 07:06, Manjari Bagchi wrote:
> I have installed from the CVS repository. I was trying to plot demo
> programmes from
> http://gnuplot.sourceforge.net/demo_4.3/transparent.html. But the demo
> programme for transparent filled curve
> (http://gnuplot.sourceforge.net/demo_4.3/transparent.2.gnu) is NOT
> working properly - it is producing solid filled curves.

What terminal type are you using?
Not all terminals support transparency [yet].
 
> Could you help me to solve this problem ?
> More over, what should I need to do if I want many filled curves with
> different opacity ?

You can append a separate fill style to each curve in the plot
command:
   plot <foo> with filledcurve fillstyle transparent solid 0.25, \
        <baz> with filledcurve fillstyle transparent solid 0.50

-- 
Ethan A Merritt

problem with gnuplot 4.3

[Manjari B. <man...@gm...>]

Hi,

I have installed from the CVS repository. I was trying to plot demo
programmes from
http://gnuplot.sourceforge.net/demo_4.3/transparent.html. But the demo
programme for transparent filled curve
(http://gnuplot.sourceforge.net/demo_4.3/transparent.2.gnu) is NOT
working properly - it is producing solid filled curves.

Could you help me to solve this problem ?
More over, what should I need to do if I want many filled curves with
different opacity ?

But I can produce transparent pattern curves as
inhttp://gnuplot.sourceforge.net/demo_4.3/transparent.4.gnu.

Thank you in advance for your kind attention.

With regards,
Manjari Bagchi

-- 
=====================================
" Be who you are and say what you feel, because
  those who mind don't matter and those who
  matter don't mind. "
  ~~~  Theodor Seuss Geisel
=====================================
  Manjari Bagchi
 Homepage:  http://www.tifr.res.in/~manjari/
 Visiting Fellow,
 Department of Astronomy and Astrophysics
  Tata Institute of Fundamental Research
  Homi Bhaba Road,
  Colaba, Mumbai 400005, India
           -------------------
Phone: +91 22 2278 2289
Fax: +91 22 2280 4610 / 11
email (official): ma...@ti...
 email (personal): man...@gm...
===============================

Re: Heavy Bug in 4.3 gnuplot

[<HBB...@t-...>]

Dietmar Warning wrote:

[A side note: there's no point Cc'ing individual members if you're 
already sending the question to the mailing list]

>          "C:\Programme\Gnuplot4.1\sg.plt", line 7: function conformal 
> requires 1 variable                                                                       

I have to agree with Ethan here --- the bug is in the script.  The newer 
gnuplot is correctly pointing out a mistake in your script.  Just 
because older versions didn't complain about it doesn't mean it's a bug 
in the new one to do so.

Re: Heavy Bug in 4.3 gnuplot

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

On Thursday 09 August 2007 11:55, Dietmar Warning wrote:
> Hello Ethan,
> 
> in working out an smith chart example the latest cvs version 4.3 doesn't 
> work with following script:
> 
> -----------------------------------------
> complex(x,y) = x*{1,0}+y*{0,1}
> conformal(z) = (z-1)/(z+1)
> 
> set parametric
> 
> a = 0
> plot real( conformal(complex(a,t), 10) ), imag(conformal(complex(a,t),10)) lt 1

Isn't that a real error in the script?
Your plot command contains a term conformal(complex(a,t), 10)
but the definition of conformal() only has one variable.

Perhaps the cvs version does more error checking, while the old
version silently ignored the extra parameter?

-- 
Ethan A Merritt

Heavy Bug in 4.3 gnuplot

[Dietmar W. <die...@ar...>]

Hello Ethan,

in working out an smith chart example the latest cvs version 4.3 doesn't 
work with following script:

-----------------------------------------
complex(x,y) = x*{1,0}+y*{0,1}
conformal(z) = (z-1)/(z+1)

set parametric

a = 0
plot real(conformal(complex(a,t),10)), imag(conformal(complex(a,t),10)) lt 1
-----------------------------------------


        G N U P L O T
        Version 4.3 patchlevel 0
        last modified June 2007
        System: MS-Windows 32 bit

        Copyright (C) 1986 - 1993, 1998, 2004, 2007
        Thomas Williams, Colin Kelley and many others

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

        Send comments and help requests to  
<gnu...@li...>

        Send bug reports and suggestions to 
<gnu...@li...>



Terminal type set to 'windows'
gnuplot> help
gnuplot> load 'C:\Programme\Gnuplot4.1\sg.plt'
         "C:\Programme\Gnuplot4.1\sg.plt", line 7: function conformal 
requires 1 
variable                                                                       




Version 4.1 works fine with this. I have looked in the help if something 
has changed in functions - but can't find anything!

Regards
Dietmar

Re: Gnuplot time is 5 hours ahead of the rest of the world

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

On Wednesday 08 August 2007 02:52, Hans-Bernhard Br=F6ker wrote:
> > This causes gnuplot's conversion from base year 1970 to 2000 to be
> > off by about 20220 seconds, which is about 5 1/2 =A0hours.
>=20
> We're not, as can be shown rather easily by looking at the relevant=20
> reference tool's output:
>=20
> $ date --date=3D'2000-01-01 00:00:00 UTC' +'%s'
> 946684800

Yes, but the code that is actually being used in time.c is this:

                /* offset from UNIX epoch (1970) to gnuplot epoch */
                static const long epoch_offset
                    =3D (long)((ZERO_YEAR - 1970) * 365.25) * DAY_SEC;

and ((ZERO_YEAR - 1970) * 365.25) * DAY_SEC
  =3D  (2000-1970) * 365.25 * 86400.0
  =3D  946728000.0

which is not the same number.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Gnuplot time is 5 hours ahead of the rest of the world

[<pl...@pi...>]

On Wed, 08 Aug 2007 11:52:33 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

>> The problem is, these values are not correct so far as I can determine.
> You determined incorrectly.

You also.

There are 7 leap years from 1.1.1970 to 1.1.2000 and 23 non leaps. So the  
application of your simplistic average is wrong.

If you want to work with a mean year length in days it is 365.233333333  
that is a difference of precisely four hours from the current value in  
gnuplot.

Since all this is UTC I suggest you look at daylight saving as a possible  
reason for the other hour of discrepancy.

regards, Peter.

Re: Gnuplot time is 5 hours ahead of the rest of the world

[<pl...@pi...>]

On Wed, 08 Aug 2007 11:52:33 +0200, Hans-Bernhard Bröker  
<HBB...@t-...> wrote:

> That's the mean number of seconds of the actual astronomical year.  But
> we're dealing with calendars here, not with astronomy.  The average
> length of a calender year, in the period under consideration (1970 to
> roughly 2038), is 365.25 days.  Multiply that by DAY_SEC and you get
> exactly those 31557600 seconds found in our YEAR_SEC.

That's the average over a period with exactly 3 non leap years and one  
leap year. This will not be the average of any arbitary period within the  
range you indicate.

What is required is the actual number of leap and non leap years an thier  
actual number of days 365/366, not an average ( I presume you are in fact  
refering to the mean rather than "average" which has several definitions).

Applying an average here is like expecting the family next door to have  
2.4 children. ;)

Re: Gnuplot time is 5 hours ahead of the rest of the world

[<HBB...@t-...>]

Ethan Merritt wrote:
> /* defines used for timeseries, seconds */
> #define ZERO_YEAR       2000
> #define JAN_FIRST_WDAY 6  /* 1st jan, 2000 is a Saturday (cal 1 2000 on unix) */
> #define SEC_OFFS_SYS    946684800.0             /*  zero gnuplot (2000) - zero system (1970) */
> #define YEAR_SEC        31557600.0      /* avg, incl. leap year */
> #define MON_SEC         2629800.0       /* YEAR_SEC / 12 */
> #define WEEK_SEC        604800.0
> #define DAY_SEC         86400.0

> The problem is, these values are not correct so far as I can determine.

You determined incorrectly.

> The actual mean number of seconds per year according to the 
> Time Service Dept of the U.S. Naval Observatory is 31556926.0

That's the mean number of seconds of the actual astronomical year.  But 
we're dealing with calendars here, not with astronomy.  The average 
length of a calender year, in the period under consideration (1970 to 
roughly 2038), is 365.25 days.  Multiply that by DAY_SEC and you get 
exactly those 31557600 seconds found in our YEAR_SEC.

> This causes gnuplot's conversion from base year 1970 to 2000 to be
> off by about 20220 seconds, which is about 5 1/2  hours.

We're not, as can be shown rather easily by looking at the relevant 
reference tool's output:

$ date --date='2000-01-01 00:00:00 UTC' +'%s'
946684800

> A symptom of this is that if you read in time data using the "%s"
> timefmt,  the time you get is wrong by 5 hours.

I'm close to 100% certain that this is not the reason.  Time zones are 
way more probable to cause that.

Re: Rounded dashed lines

[Theo H. <th...@ph...>]

Ethan Merritt wrote:
> On Tuesday 07 August 2007 11:11, Theo Hopman wrote:
>> Hi all. I'm not really sure why this happens, but if I create a graph in 
>> gnuplot using the epslatex (or even just plain postscript) terminal with 
>> rounded and dashed lines, the dashed lines come out as solid lines when 
>> I convert to PDF with either Distiller or epstopdf. Why? The dashed 
>> lines show up fine in the eps file when I preview it.
> 
> Works fine here using either ps2pdf from ghostscript version 8.15.3
> or epstopdf from pdfeTeX 3.141592-1.30.6-2.2
> 
> Is it possible that your pdf file is OK, but your pdf viewer does not
> handle it correctly?

Huh... PDF file is OK when viewed with gsview and with Acrobat 7.0, but 
not with Reader/Acrobat 8.0. Very weird.

THeo

Gnuplot time is 5 hours ahead of the rest of the world

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

gp_time.h contains the following definitions:

/* defines used for timeseries, seconds */
#define ZERO_YEAR       2000
#define JAN_FIRST_WDAY 6  /* 1st jan, 2000 is a Saturday (cal 1 2000 on unix) */
#define SEC_OFFS_SYS    946684800.0             /*  zero gnuplot (2000) - zero system (1970) */
#define YEAR_SEC        31557600.0      /* avg, incl. leap year */
#define MON_SEC         2629800.0       /* YEAR_SEC / 12 */
#define WEEK_SEC        604800.0
#define DAY_SEC         86400.0

The problem is, these values are not correct so far as I can determine.

The actual mean number of seconds per year according to the 
Time Service Dept of the U.S. Naval Observatory is 31556926.0

This causes gnuplot's conversion from base year 1970 to 2000 to be
off by about 20220 seconds, which is about 5 1/2  hours.

A symptom of this is that if you read in time data using the "%s"
timefmt,  the time you get is wrong by 5 hours.

Is there any reason we should tolerate this level of error?

It seems very strange that anyone would have gone to the trouble
of working out the zero point offsets, but failed to notice a 5 hour
error.  Am I missing something here?

-- 
Ethan A Merritt

Re: Rounded dashed lines

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

On Tuesday 07 August 2007 11:11, Theo Hopman wrote:
> Hi all. I'm not really sure why this happens, but if I create a graph in 
> gnuplot using the epslatex (or even just plain postscript) terminal with 
> rounded and dashed lines, the dashed lines come out as solid lines when 
> I convert to PDF with either Distiller or epstopdf. Why? The dashed 
> lines show up fine in the eps file when I preview it.

Works fine here using either ps2pdf from ghostscript version 8.15.3
or epstopdf from pdfeTeX 3.141592-1.30.6-2.2

Is it possible that your pdf file is OK, but your pdf viewer does not
handle it correctly?


-- 
Ethan A Merritt