gnuplot development

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

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 <slabinsk@...>
> To: HBBroeker@..., Harald.Soelter@...
> CC: USNO Office <slabinski.victor@...
> gnuplot-bugs@..., gnuplot-info@...
>=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
> gnuplot-beta@...
> 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

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

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 <slabinsk@...>
To: HBBroeker@..., Harald.Soelter@...
CC: USNO Office <slabinski.victor@...>, 
gnuplot-bugs@..., gnuplot-info@...

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

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

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

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

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): manjari@...
 email (personal): manjari.bagchi@...
===============================

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  
<gnuplot-beta@...>

        Send bug reports and suggestions to 
<gnuplot-beta@...>



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

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.

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