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

Re: sprintf() error (compiled by VC++)

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

On Thursday, October 06, 2011 03:46:13 pm Hans-Bernhard Bröker wrote:
> On 06.10.2011 10:01, Shigeharu TAKENO wrote:
> 
> > I saw that gnuplot.exe of CVS version compiled by VC++ reports
> [...]
> >    foo = sprintf("%40d %40d %40d %40d %40d %40d",1,2,3,4,5,6)
> >          ^
> >    "stringvar.dem", line 59: undefined value
> 
> For what it's worth: this program doesn't appear in gnuplot.exe compiled 
> by Open Watcom.
> 
> > The gnuplot show no erorr message for the command
> >
> >    foo = sprintf("%83d",1)
> >
> > but it show the same error message above for the command
> >
> >    foo = sprintf("%84d",1)
> 
> This doesn't cause problem either.
> 
> The root of the problem appears to be the buffer size computation and 
> subsequent realloc()ation in f_sprintf().  The number 84 is magic 
> because it's 84 plus the length of the format string "%84d".  Go figure.

The problem occurs when the platform/compiler does not support snprintf.
f_sprintf() has:

#ifdef HAVE_SNPRINTF
        /* Use the format to print next arg */
    ... this code works fine ...
#else
        /* FIXME - this is bad; we should dummy up an snprintf equivalent */
    ... this code triggers a buffer overflow if the format width is too large
#endif

So the FIXME comment is correct.
	
	Ethan

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: sprintf() error (compiled by VC++)

[Hans-Bernhard B. <HBB...@t-...>]

On 06.10.2011 10:01, Shigeharu TAKENO wrote:

> I saw that gnuplot.exe of CVS version compiled by VC++ reports
[...]
>    foo = sprintf("%40d %40d %40d %40d %40d %40d",1,2,3,4,5,6)
>          ^
>    "stringvar.dem", line 59: undefined value

For what it's worth: this program doesn't appear in gnuplot.exe compiled 
by Open Watcom.

> The gnuplot show no erorr message for the command
>
>    foo = sprintf("%83d",1)
>
> but it show the same error message above for the command
>
>    foo = sprintf("%84d",1)

This doesn't cause problem either.

The root of the problem appears to be the buffer size computation and 
subsequent realloc()ation in f_sprintf().  The number 84 is magic 
because it's 84 plus the length of the format string "%84d".  Go figure.

sprintf() error (compiled by VC++)

[Shigeharu T. <sh...@ie...>]

shige 10/06 2011
----------------

I saw that gnuplot.exe of CVS version compiled by VC++ reports 
some errors for demo/stringvar.dem. Two errors of them are for
system() and they are not strange because I compiled without the
macro PIPES. But the rest one is odd:

  foo = sprintf("%40d %40d %40d %40d %40d %40d",1,2,3,4,5,6)
        ^
  "stringvar.dem", line 59: undefined value

The gnuplot show no erorr message for the command

  foo = sprintf("%83d",1)

but it show the same error message above for the command

  foo = sprintf("%84d",1)

I don't know why this happens.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: data and function plot causing double assignment

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

On Tuesday, October 04, 2011 10:03:10 am pl...@pi... wrote:
> On 10/04/11 18:22, Ethan Merritt wrote:
> > On Tuesday, October 04, 2011 08:43:02 am pl...@pi... wrote:
> >> On 10/04/11 17:28, Ethan Merritt wrote:
> >>> On Tuesday, 04 October 2011, pl...@pi... wrote:
> >>>> Hi,
> >>>>
> >>>> I have found what appears to be a defect in variable assignments in plot.
> >>>>
> >>>> gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
> >>>> a1=a0;b1=b0;c1=c0;pk0=-141;
> >>>> add_one(x)=area0=1;
> >>>
> >>> This defines the function add_one(x)
> >>> to be  add_one(x) =   value of (area0=1)
> >>>                     = 1
> >>> So add_one(x) = 1 for all x
> >>
> >> Exactly, so why is area still 0 after having been assigned the value 1
> >> about 512 times?!
> >
> > Ah. I thought you were asking about the behaviour of add_one(),
> > since its name implies that it performs an addition but in fact it
> > is defined to always equal 1.  I wondered if you didn't simply have
> > a typo for   "add_one_x = area0 +1".
> > Anyhow...
> >
> >> I reiterate that if I remove the function plot I do get areas=1 after
> >> plotting. This indicates that plot is re-executing area0=0 after the
> >> second data plot and before plotting the function.
> >
> > I don't say this is good/bad, expected/unexpected, bug/feature, or simply
> > confusing, but this is the way it has always worked.  Each plot command
> > is evaluated once to detect functions, read in data, and determine plot
> > ranges; then it is evaluated again to fill in function values over the
> > now-determined range; then it is plotted.   If there are no functions then
> > the second of those three operations is skipped.
> >
> > See also
> >    https://sourceforge.net/tracker/index.php?func=detail&aid=2907028&group_id=2055&atid=102055
> >
> > 	Ethan
> > #
> Thanks ,  I can understand that bug report and how your explanation 
> above accounts for what was reported. However, it does not seem to 
> explain what I'm seeing.
> 
> Is the order perhaps:
> evaluate
> plot data
> evaluate
> plot functions
> ?

Nope.    
Code snippetes from plot2d.c

    /* ** First Pass: Read through data files ***
     * This pass serves to set the xrange and to parse the command, as well
     * as filling in every thing except the function data. That is done after
     * the xrange is defined.
     */
[...]
/*** Second Pass: Evaluate the functions ***/
    /*
     * Everything is defined now, except the function data. We expect
     * no syntax errors, etc, since the above parsed it all. This
     * makes the code below simpler. If y is autoscaled, the yrange
     * may still change.  we stored last token of each plot, so we
     * dont need to do everything again */
[...]
    if (some_functions) {
[...]
    }   /* some_functions */
[...]

    if (table_mode) {
        print_table(first_plot, plot_num);

    } else {
        /* do_plot now uses axis_array[] */
        do_plot(first_plot, plot_num);
    }


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: data and function plot causing double assignment

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

On 10/04/11 18:22, Ethan Merritt wrote:
> On Tuesday, October 04, 2011 08:43:02 am pl...@pi... wrote:
>> On 10/04/11 17:28, Ethan Merritt wrote:
>>> On Tuesday, 04 October 2011, pl...@pi... wrote:
>>>> Hi,
>>>>
>>>> I have found what appears to be a defect in variable assignments in plot.
>>>>
>>>> gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
>>>> a1=a0;b1=b0;c1=c0;pk0=-141;
>>>> add_one(x)=area0=1;
>>>
>>> This defines the function add_one(x)
>>> to be  add_one(x) =   value of (area0=1)
>>>                     = 1
>>> So add_one(x) = 1 for all x
>>
>> Exactly, so why is area still 0 after having been assigned the value 1
>> about 512 times?!
>
> Ah. I thought you were asking about the behaviour of add_one(),
> since its name implies that it performs an addition but in fact it
> is defined to always equal 1.  I wondered if you didn't simply have
> a typo for   "add_one_x = area0 +1".
> Anyhow...
>
>> I reiterate that if I remove the function plot I do get areas=1 after
>> plotting. This indicates that plot is re-executing area0=0 after the
>> second data plot and before plotting the function.
>
> I don't say this is good/bad, expected/unexpected, bug/feature, or simply
> confusing, but this is the way it has always worked.  Each plot command
> is evaluated once to detect functions, read in data, and determine plot
> ranges; then it is evaluated again to fill in function values over the
> now-determined range; then it is plotted.   If there are no functions then
> the second of those three operations is skipped.
>
> See also
>    https://sourceforge.net/tracker/index.php?func=detail&aid=2907028&group_id=2055&atid=102055
>
> 	Ethan
> #
Thanks ,  I can understand that bug report and how your explanation 
above accounts for what was reported. However, it does not seem to 
explain what I'm seeing.

Is the order perhaps:
evaluate
plot data
evaluate
plot functions
?
regards.



>> /Peter.
>>
>>
>>> Any later changes to the value of area0 are not relevant.
>>>
>>> 	Ethan
>>>
>>>> plot  area0=0\
>>>> , datafile using 1:(add_one($2)) w l\
>>>> , datafile using 1:(($2)) w l\
>>>> , gauss0(x) tit 'fitted peak0'\
>>>>
>>>> print "area0=",area0;
>>>>
>>>> I was expecting this to do the assignment area0=0 once and once only
>>>> before any of the lines were plotted.
>>>>
>>>> It is only assigned once for the datafile plots but adding the function
>>>> plot causes this snippet to print a value of zero , not one.
>>>>
>>>> I am inferring that using a mix of data and function plots is causing
>>>> the initial assignment to be done twice.  Bug or feature?
>>>>
>>>> best regards, Peter.
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure contains a
>>>> definitive record of customers, application performance, security
>>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>>> sense of it. Business sense. IT sense. Common sense.
>>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>>> _______________________________________________
>>>> gnuplot-beta mailing list
>>>> gnu...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>>>
>>>
>>>
>>
>>
>

Re: data and function plot causing double assignment

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

On Tuesday, October 04, 2011 08:43:02 am pl...@pi... wrote:
> On 10/04/11 17:28, Ethan Merritt wrote:
> > On Tuesday, 04 October 2011, pl...@pi... wrote:
> >> Hi,
> >>
> >> I have found what appears to be a defect in variable assignments in plot.
> >>
> >> gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
> >> a1=a0;b1=b0;c1=c0;pk0=-141;
> >> add_one(x)=area0=1;
> >
> > This defines the function add_one(x)
> > to be  add_one(x) =   value of (area0=1)
> >                    = 1
> > So add_one(x) = 1 for all x
> 
> Exactly, so why is area still 0 after having been assigned the value 1 
> about 512 times?!

Ah. I thought you were asking about the behaviour of add_one(),
since its name implies that it performs an addition but in fact it
is defined to always equal 1.  I wondered if you didn't simply have
a typo for   "add_one_x = area0 +1".  
Anyhow...

> I reiterate that if I remove the function plot I do get areas=1 after 
> plotting. This indicates that plot is re-executing area0=0 after the 
> second data plot and before plotting the function.

I don't say this is good/bad, expected/unexpected, bug/feature, or simply
confusing, but this is the way it has always worked.  Each plot command
is evaluated once to detect functions, read in data, and determine plot
ranges; then it is evaluated again to fill in function values over the
now-determined range; then it is plotted.   If there are no functions then
the second of those three operations is skipped.

See also
  https://sourceforge.net/tracker/index.php?func=detail&aid=2907028&group_id=2055&atid=102055

	Ethan

> /Peter.
> 
> 
> > Any later changes to the value of area0 are not relevant.
> >
> > 	Ethan
> >
> >> plot  area0=0\
> >> , datafile using 1:(add_one($2)) w l\
> >> , datafile using 1:(($2)) w l\
> >> , gauss0(x) tit 'fitted peak0'\
> >>
> >> print "area0=",area0;
> >>
> >> I was expecting this to do the assignment area0=0 once and once only
> >> before any of the lines were plotted.
> >>
> >> It is only assigned once for the datafile plots but adding the function
> >> plot causes this snippet to print a value of zero , not one.
> >>
> >> I am inferring that using a mix of data and function plots is causing
> >> the initial assignment to be done twice.  Bug or feature?
> >>
> >> best regards, Peter.
> >>
> >> ------------------------------------------------------------------------------
> >> All the data continuously generated in your IT infrastructure contains a
> >> definitive record of customers, application performance, security
> >> threats, fraudulent activity and more. Splunk takes this data and makes
> >> sense of it. Business sense. IT sense. Common sense.
> >> http://p.sf.net/sfu/splunk-d2dcopy1
> >> _______________________________________________
> >> gnuplot-beta mailing list
> >> gnu...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> >>
> >
> >
> 
> 

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: data and function plot causing double assignment

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

On 10/04/2011 10:43 AM, pl...@pi... wrote:
> On 10/04/11 17:28, Ethan Merritt wrote:
>> On Tuesday, 04 October 2011, pl...@pi... wrote:
>>> Hi,
>>>
>>> I have found what appears to be a defect in variable assignments in plot.
>>>
>>> gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
>>> a1=a0;b1=b0;c1=c0;pk0=-141;
>>> add_one(x)=area0=1;
>>
>> This defines the function add_one(x)
>> to be  add_one(x) =   value of (area0=1)
>>                     = 1
>> So add_one(x) = 1 for all x
>
> Exactly, so why is area still 0 after having been assigned the value 1
> about 512 times?!

Where is the value of area0 used in this set of instructions?  I'm 
wondering if it is used as a value somewhere in the plots what its value 
is when utilized (0 or 1)?

There is some ambiguity here in this statement:

add_one(x)=area0=1;

Does it mean add_one(x)=(area0=1)?  Or (add_one(x)=area0)=1?  It could 
also be that every time there is a set of data for a new plot inside of 
"datafile", area0 is reset to 0.  And possibly that gnuplot is 
programmed so that area0 is set to zero, THEN check whether there is 
more data to plot.  (And one could argue that is unintended, but again 
it has to be defined in documentation to remove ambiguity.)  Could you 
explore things a little more by using the value of area0 inside the 
plots and figure out from the plots what value of area0 is being used?

Dan


> I reiterate that if I remove the function plot I do get areas=1 after
> plotting. This indicates that plot is re-executing area0=0 after the
> second data plot and before plotting the function.
>
> /Peter.
>
>
>> Any later changes to the value of area0 are not relevant.
>>
>> 	Ethan
>>
>>> plot  area0=0\
>>> , datafile using 1:(add_one($2)) w l\
>>> , datafile using 1:(($2)) w l\
>>> , gauss0(x) tit 'fitted peak0'\
>>>
>>> print "area0=",area0;
>>>
>>> I was expecting this to do the assignment area0=0 once and once only
>>> before any of the lines were plotted.
>>>
>>> It is only assigned once for the datafile plots but adding the function
>>> plot causes this snippet to print a value of zero , not one.
>>>
>>> I am inferring that using a mix of data and function plots is causing
>>> the initial assignment to be done twice.  Bug or feature?
>>>
>>> best regards, Peter.
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure contains a
>>> definitive record of customers, application performance, security
>>> threats, fraudulent activity and more. Splunk takes this data and makes
>>> sense of it. Business sense. IT sense. Common sense.
>>> http://p.sf.net/sfu/splunk-d2dcopy1
>>> _______________________________________________
>>> gnuplot-beta mailing list
>>> gnu...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> 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://www(DOT)dansebald(DOT)com

Re: data and function plot causing double assignment

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

On 10/04/11 17:28, Ethan Merritt wrote:
> On Tuesday, 04 October 2011, pl...@pi... wrote:
>> Hi,
>>
>> I have found what appears to be a defect in variable assignments in plot.
>>
>> gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
>> a1=a0;b1=b0;c1=c0;pk0=-141;
>> add_one(x)=area0=1;
>
> This defines the function add_one(x)
> to be  add_one(x) =   value of (area0=1)
>                    = 1
> So add_one(x) = 1 for all x

Exactly, so why is area still 0 after having been assigned the value 1 
about 512 times?!

I reiterate that if I remove the function plot I do get areas=1 after 
plotting. This indicates that plot is re-executing area0=0 after the 
second data plot and before plotting the function.

/Peter.


> Any later changes to the value of area0 are not relevant.
>
> 	Ethan
>
>> plot  area0=0\
>> , datafile using 1:(add_one($2)) w l\
>> , datafile using 1:(($2)) w l\
>> , gauss0(x) tit 'fitted peak0'\
>>
>> print "area0=",area0;
>>
>> I was expecting this to do the assignment area0=0 once and once only
>> before any of the lines were plotted.
>>
>> It is only assigned once for the datafile plots but adding the function
>> plot causes this snippet to print a value of zero , not one.
>>
>> I am inferring that using a mix of data and function plots is causing
>> the initial assignment to be done twice.  Bug or feature?
>>
>> best regards, Peter.
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense.
>> http://p.sf.net/sfu/splunk-d2dcopy1
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>

Re: data and function plot causing double assignment

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

On Tuesday, 04 October 2011, pl...@pi... wrote:
> Hi,
> 
> I have found what appears to be a defect in variable assignments in plot.
> 
> gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
> a1=a0;b1=b0;c1=c0;pk0=-141;
> add_one(x)=area0=1;

This defines the function add_one(x)
to be  add_one(x) =   value of (area0=1)
                  = 1
So add_one(x) = 1 for all x
Any later changes to the value of area0 are not relevant.

	Ethan

> plot  area0=0\
> , datafile using 1:(add_one($2)) w l\
> , datafile using 1:(($2)) w l\
> , gauss0(x) tit 'fitted peak0'\
> 
> print "area0=",area0;
> 
> I was expecting this to do the assignment area0=0 once and once only 
> before any of the lines were plotted.
> 
> It is only assigned once for the datafile plots but adding the function 
> plot causes this snippet to print a value of zero , not one.
> 
> I am inferring that using a mix of data and function plots is causing 
> the initial assignment to be done twice.  Bug or feature?
> 
> best regards, Peter.
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

data and function plot causing double assignment

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

Hi,

I have found what appears to be a defect in variable assignments in plot.

gauss0(x)=a0*exp(-(x-pk0)**2/b0)+c0
a1=a0;b1=b0;c1=c0;pk0=-141;
add_one(x)=area0=1;
plot  area0=0\
, datafile using 1:(add_one($2)) w l\
, datafile using 1:(($2)) w l\
, gauss0(x) tit 'fitted peak0'\

print "area0=",area0;

I was expecting this to do the assignment area0=0 once and once only 
before any of the lines were plotted.

It is only assigned once for the datafile plots but adding the function 
plot causes this snippet to print a value of zero , not one.

I am inferring that using a mix of data and function plots is causing 
the initial assignment to be done twice.  Bug or feature?

best regards, Peter.

Re: plotting limitted range still going though all data

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

On Friday, September 30, 2011 02:28:09 pm pl...@pi... wrote:
> On 09/30/11 23:06, Ethan Merritt wrote:
> > On Friday, September 30, 2011 12:20:57 pm pl...@pi... wrote:
> >> Hi,
> >>
> >> I am calling a simple function max() to detect the two largest peaks in
> >> the data.
> >>
> >>
> >> #function to do sample/hold
> >> max(x,y)=(ymax<y) ? ( xmax=x, ymax=y) :ymax ;
> >>
> >> # dummy plot to scan data for biggest peak
> >> set term unknown
> >> plot ymax=xmax=0,  datafile using 1:( max(($1),($2)) );
> >> pk0=xmax; ymax=xmax=0;
> >> plot  [pk0+100:]  datafile using 1:( max(($1),($2)) );
> >> pk1=xmax;
> >
> >> It's hitting the first one both times.
> >
> >> Now unless I'm getting sleepy, this seems to show that the second call
> >> to plot with a specified limited range is still going through the
> >> motions. and evaluating the using clause for all data points in the
> >> file. Thus all the mechanics are still being gone through only to have
> >> null output created.
> >
> > How would it know if $1 and/or $2 are out of range without
> > evaluating them first?
> >
> clearly it has to read the data lines but what needs evaluating, then 
> range is a given constant.
> 
> It seems it is evaluation the using clause , yet this is not what the 
> range applies to , it applies to $1.
> 
> Am I mistaken?

You are mistaken.  The xrange applies to whatever expression is
evaluated in the first field of the 'using' clause.
Another way of stating this is that xrange applies (logically enough)
to the range of the x axis of the plot.  It does not depend on the
numerical contents of any data file.

Consider the following plot:
   plot '-' using ($1/10.):($2/10.)
   10 50
   20 50
   30 40
   40 60
   50 40
   60 60
   70  0
   e

This generates a plot where the x axis runs from 1->7 and the y axis
runs from 0->5.
If you first do
   set xrange [0:9]
this will actually _expand_ the xrange. Certainly it will not
reject all the data points.


-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

Re: plotting limitted range still going though all data

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

On 09/30/11 23:06, Ethan Merritt wrote:
> On Friday, September 30, 2011 12:20:57 pm pl...@pi... wrote:
>> Hi,
>>
>> I am calling a simple function max() to detect the two largest peaks in
>> the data.
>>
>>
>> #function to do sample/hold
>> max(x,y)=(ymax<y) ? ( xmax=x, ymax=y) :ymax ;
>>
>> # dummy plot to scan data for biggest peak
>> set term unknown
>> plot ymax=xmax=0,  datafile using 1:( max(($1),($2)) );
>> pk0=xmax; ymax=xmax=0;
>> plot  [pk0+100:]  datafile using 1:( max(($1),($2)) );
>> pk1=xmax;
>
>> It's hitting the first one both times.
>
>> Now unless I'm getting sleepy, this seems to show that the second call
>> to plot with a specified limited range is still going through the
>> motions. and evaluating the using clause for all data points in the
>> file. Thus all the mechanics are still being gone through only to have
>> null output created.
>
> How would it know if $1 and/or $2 are out of range without
> evaluating them first?
>
clearly it has to read the data lines but what needs evaluating, then 
range is a given constant.

It seems it is evaluation the using clause , yet this is not what the 
range applies to , it applies to $1.

Am I mistaken?

>> Is this :
>>
>> ?
>> a) correctly what's happening
>> b) necessary
>> c) desirable.
>>
>> ?
>>
>> If I have a huge data file (that I do sometimes.) it would seem
>> advantageous if setting a range pre-empted the rest of plot activity
>> until the range condition is true.
>>
>> Best regards. Peter.
>
> If the values in column(1) are monotonic increasing in your data file,
> then you can skip the leading N records via the "plot ... using every ..."
> option.  Otherwise each line will be processed and stored with flag
> INRANGE/OUTRANGE/UNDEFINED as appropriate.  After all the data records
> are read in, the INRANGE points are plotted.
> Does that answer the question?
>

Re: plotting limitted range still going though all data

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

On Friday, September 30, 2011 12:20:57 pm pl...@pi... wrote:
> Hi,
> 
> I am calling a simple function max() to detect the two largest peaks in 
> the data.
> 
> 
> #function to do sample/hold
> max(x,y)=(ymax<y) ? ( xmax=x, ymax=y) :ymax ;
> 
> # dummy plot to scan data for biggest peak
> set term unknown
> plot ymax=xmax=0,  datafile using 1:( max(($1),($2)) );
> pk0=xmax; ymax=xmax=0;
> plot  [pk0+100:]  datafile using 1:( max(($1),($2)) );
> pk1=xmax;

> It's hitting the first one both times.

> Now unless I'm getting sleepy, this seems to show that the second call 
> to plot with a specified limited range is still going through the 
> motions. and evaluating the using clause for all data points in the 
> file. Thus all the mechanics are still being gone through only to have 
> null output created.

How would it know if $1 and/or $2 are out of range without
evaluating them first?

> Is this :
> 
> ?
> a) correctly what's happening
> b) necessary
> c) desirable.
> 
> ?
> 
> If I have a huge data file (that I do sometimes.) it would seem 
> advantageous if setting a range pre-empted the rest of plot activity 
> until the range condition is true.
> 
> Best regards. Peter.

If the values in column(1) are monotonic increasing in your data file,
then you can skip the leading N records via the "plot ... using every ..." 
option.  Otherwise each line will be processed and stored with flag 
INRANGE/OUTRANGE/UNDEFINED as appropriate.  After all the data records
are read in, the INRANGE points are plotted.  
Does that answer the question?

-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742

plotting limitted range still going though all data

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

Hi,

I am calling a simple function max() to detect the two largest peaks in 
the data.


#function to do sample/hold
max(x,y)=(ymax<y) ? ( xmax=x, ymax=y) :ymax ;

# dummy plot to scan data for biggest peak
set term unknown
plot ymax=xmax=0,  datafile using 1:( max(($1),($2)) );
pk0=xmax; ymax=xmax=0;
plot  [pk0+100:]  datafile using 1:( max(($1),($2)) );
pk1=xmax;
set term ''

if (debugging) print "xmax = ",xmax,"; ymax  ",ymax; pause mouse


It's hitting the first one both times.

Now unless I'm getting sleepy, this seems to show that the second call 
to plot with a specified limited range is still going through the 
motions. and evaluating the using clause for all data points in the 
file. Thus all the mechanics are still being gone through only to have 
null output created.

Is this :

?
a) correctly what's happening
b) necessary
c) desirable.

?

If I have a huge data file (that I do sometimes.) it would seem 
advantageous if setting a range pre-empted the rest of plot activity 
until the range condition is true.

Best regards. Peter.

Re: Release plans: Version 4.4.4 and beyond

[sfeam (E. Merritt) <eam...@gm...>]

On Tuesday, 13 September 2011, Hans-Bernhard Bröker wrote:
> On 13.09.2011 23:59, Ethan A Merritt wrote:
> 
> > - The PostScript terminal driver is inconsistent with all other terminal
> >    drivers with regard to the "set size" command.
> 
> ... that's true in no small part only because you bodily removed a good 
> number of other drivers that behaved the same way.

Terminals removed since version 4.0:
    amiga apollo atari fg gnugraph gpr iris4d mgr multitos
    png(libpng) rgip unixplot

None of those have been remotely relevant for the last decade.
Who cares now what they did about "set size"?

> > - The pieces are in place to support "dashtype" as a line property.
> >    The current syntax overloads "linetype" to mean a combination of dash
> >    properties, color properties, and width.
> 
> That one had me completely puzzled when I (belatedly) saw it mentioned. 
>   What was so bad about 'set style line' that its functionality needed 
> to be duplicated and incompatibly overloaded onto pre-existing syntax?

Clarify please. Nothing has changed about 'set style line' that I know of.

> Since the addition of 'linecolor' ages ago, 'linetype' already controls 
> basically nothing but dashtype.  What would be the benefit of changing 
> the name?

I think we're talking at cross-purposes.  The issue is that if you write
a script that refers to linetypes, it does different things depending on
whether you say "set term post solid color" or "set term post dashed mono".
The terminal itself changes how linetype is interpreted.  

The other point is that you can [now] force the color regardless of the
terminal's own defaults.  But there is no way to force the dash type;
you can only use the terminal defaults.

> It would be a good deal less intrusive to add a new sub-command to 'set 
> style' that just turns off the influence of linetype numbers on the 
> default(!) line colours.

Less intrusive than what?

> > - The "call" command no longer makes any sense, and arguably is broken.
> >    (I can't find the discussion we had about this, but it must have been
> >    about 2 years ago?).
> 
> I have not the slightest memory of such a discussion ever having taken 
> place.  Nor do I see how call might no longer make any sense.

Variables are persistent across 'load foo' anyhow.  There is no need
for a separate mechanism 'call foo var1 var2 var3'.
Brokenness: the call mechanism does not handle strings (understandable
since they didn't exist at the time it was written).

	Ethan

Re: Release plans: Version 4.4.4 and beyond

[Hans-Bernhard B. <HBB...@t-...>]

On 13.09.2011 23:59, Ethan A Merritt wrote:

> So then let's ask the question "Are there changes we held off from
> making because they would break backwards compatibility?"

> - We're still carrying around a bunch of conditional code under the control
>    of --enable-backwards-compatibility.  This could go away.

Or we could put more old syntax we no longer want to support in the 
default under control of the existing switch.  And maybe just drop the 
remainder of the support for stuff that has been in this box since 
version 4.0.

> - The PostScript terminal driver is inconsistent with all other terminal
>    drivers with regard to the "set size" command.

... that's true in no small part only because you bodily removed a good 
number of other drivers that behaved the same way.

> - The binary input code needs to be rewritten, if not replaced, and the
>    revised version may well not be able to fully maintain the original
>    syntax.  It would be nice, for example, if the options controlling
>    matrix/array input for ascii and binary files were consistent rather
>    than re-using the same keywords for conflicting purposes.

Now we're getting somewhere.  That's an externally visible change to the 
main command syntax, and thus would warrant a major version number bump.

> - The pieces are in place to support "dashtype" as a line property.
>    The current syntax overloads "linetype" to mean a combination of dash
>    properties, color properties, and width.

That one had me completely puzzled when I (belatedly) saw it mentioned. 
  What was so bad about 'set style line' that its functionality needed 
to be duplicated and incompatibly overloaded onto pre-existing syntax?

Since the addition of 'linecolor' ages ago, 'linetype' already controls 
basically nothing but dashtype.  What would be the benefit of changing 
the name?

It would be a good deal less intrusive to add a new sub-command to 'set 
style' that just turns off the influence of linetype numbers on the 
default(!) line colours.

> - The "call" command no longer makes any sense, and arguably is broken.
>    (I can't find the discussion we had about this, but it must have been
>    about 2 years ago?).

I have not the slightest memory of such a discussion ever having taken 
place.  Nor do I see how call might no longer make any sense.

> - The alpha-channel representation of transparency used by "set style fill"
>    and by plot style "with rgbalpha" are inconsistent.  I'll accept the
>    blame for this.  Anyhow, I've held off work on supporting a general
>    rgba color mode  ( e.g. plot ... linecolor rgba "#3FAABBCC" ) because
>    of the inconsistency.  Easy enough to change the interpretation of
>    "set style fill transparent ...", but it would invert the meaning of
>    existing scripts.

That, along with some of the other plans you brought up, looks like a 
rather good reason to put out a 4.6 release _before_ embarking on that 
journey.  I.e. first make sure we have something to give people who want 
the new features in today's development version, with an official 
version stamp on it, and thus buy ourselves the time to perform major 
reworks that might make things worse for a while, before they get better.

When we find ourselves frequently replying on the newsgroup: "but you 
need the development version for that", that means a new release on the 
trunk is in order.  I think we've reached this point about half a year 
ago.  So it's clear that the 4.4 branch should be ended soon, and 
replaced by a branch starting at the current CVS head.

The question I see as open is whether the changes present in today's 
warrant a 5.0 version number.  Things that are currently just plans 
should not factor into that decision.

> If we do go with a 4.6 release rather than 5.0, maybe these and other
> potential areas should be prominently marked DEPRECATED or MAY CHANGE?

To the extent such plans are, indeed, known and accepted at the time of 
a 4.6 release, sure.

Re: Release plans: Version 4.4.4 and beyond

[Ethan A M. <sf...@us...>]

On Tuesday, September 13, 2011 05:54:07 am Hans-Bernhard Bröker wrote:
> On 12.09.2011 05:50, sfeam (Ethan Merritt) wrote:
> 
> > The chief arguments I see for bumping the version to 5
> > (rather than 4.6):
> >
> > 1) The code in the development branch has diverged enough from the
> > code in the version 4 branch that most new patches cannot be easily
> > back-ported.
> 
> > 2) There are significant syntax and UI changes already in or queued for
> > the development branch [...]
> 
> I consider those good reasons to make a new non-patchlevel release, but 
> I don't see the case for a major version number step.  Those should IMHO 
> be reserved for user-visible, _incomptabible_ changes.  I.e. as long as 
> basically all scripts written for version 4.0 (or maybe 4.4) still work, 
> I don't quite see a reason to bump to 5.0.

So then let's ask the question "Are there changes we held off from
making because they would break backwards compatibility?"

I can think of several.

- We're still carrying around a bunch of conditional code under the control
  of --enable-backwards-compatibility.  This could go away.  I don't know
  a good way to find out how many people use this configuration option, but
  it isn't enabled in the linux distro packages I looked at.

- The PostScript terminal driver is inconsistent with all other terminal
  drivers with regard to the "set size" command.  Also it causes confusion
  that the font size in "eps" output is only half what the user requests.
  The "fontscale" option was a messy attempt to paper this over, but it
  causes additional confusion (if in fact people even realize it exists).  
  Oh, and the sequence of dash patterns in post.trm is different from
  all others.  Why on earth isn't linetype 1 a solid line????
  We could bring post.trm into better agreement with the newer terminals.

- The binary input code needs to be rewritten, if not replaced, and the
  revised version may well not be able to fully maintain the original
  syntax.  It would be nice, for example, if the options controlling
  matrix/array input for ascii and binary files were consistent rather
  than re-using the same keywords for conflicting purposes.

- The introduction of command line macros (./configure --enable-macros)
  was an early attempt to support string substitution.  I believe it
  offers no functionality that isn't better handled using string functions.
  We could get rid of this conditional code.

- The pieces are in place to support "dashtype" as a line property.
  The current syntax overloads "linetype" to mean a combination of dash
  properties, color properties, and width.   Version 5 would be a great
  opportunity to clean this up and support a real "dashtype" property,
  but it would break old scripts that assume line color and dash pattern
  are really the same thing.

- The "call" command no longer makes any sense, and arguably is broken.
  (I can't find the discussion we had about this, but it must have been
  about 2 years ago?).  Let's get rid of it.

- The alpha-channel representation of transparency used by "set style fill"
  and by plot style "with rgbalpha" are inconsistent.  I'll accept the
  blame for this.  Anyhow, I've held off work on supporting a general
  rgba color mode  ( e.g. plot ... linecolor rgba "#3FAABBCC" ) because
  of the inconsistency.  Easy enough to change the interpretation of
  "set style fill transparent ...", but it would invert the meaning of
  existing scripts.

If we do go with a 4.6 release rather than 5.0, maybe these and other 
potential areas should be prominently marked DEPRECATED or MAY CHANGE?

		Ethan

Re: Release plans: Version 4.4.4 and beyond

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

On 09/11/2011 10:50 PM, sfeam (Ethan Merritt) wrote:

> Beyond
> ======
>
> After releasing 4.4.4, I am thinking that we should re-tag the CVS
> tree as the development branch for gnuplot version 5 and plan to
> put out a version 5.0 release candidate sometime after the New Year,
> aiming for a full release in the Spring.
>
> The chief arguments I see for bumping the version to 5
> (rather than 4.6):
>
> 1) The code in the development branch has diverged enough from the
> code in the version 4 branch that most new patches cannot be easily
> back-ported.
>
> 2) There are significant syntax and UI changes already in or queued for
> the development branch, notably
> - block-structured if/else/do/for/while statements
> - nested iteration
> - local customization of linetypes using "set linetype"
> - tab completion and UTF-8 support in the builtin readline
> - reworked Windows driver
> - "stats" subsystem (Patchset #2894333)
>
> and probably more I'm not thinking of at the moment.
>
> What do you think?

I've been itching to revisit the hidden surface issues with gnuplot and 
give that a shot.  If I remember correctly, there was someone from South 
America who submitted a hunk of code for breaking up intersecting 
triangular surface elements.  There is much more to it, naturally, but I 
think using the hidden line code as a base should get us to an eventual 
implementation.  The painter's algorithm of PM3D is very limited and 
just isn't amenable to true hidden surface.

The first pass would be an all triangles implementation that will 
probably be slow and have dithering issues for surfaces that perfectly 
coincide.  However, once that far, input from all developers for speed 
improvements should get things rolling where it might make a good 
feature for a 5.0 version in the six month time frame.

Dan

Re: Release plans: Version 4.4.4 and beyond

[Hans-Bernhard B. <HBB...@t-...>]

On 12.09.2011 05:50, sfeam (Ethan Merritt) wrote:

> The chief arguments I see for bumping the version to 5
> (rather than 4.6):
>
> 1) The code in the development branch has diverged enough from the
> code in the version 4 branch that most new patches cannot be easily
> back-ported.

> 2) There are significant syntax and UI changes already in or queued for
> the development branch, notably

[...]

I consider those good reasons to make a new non-patchlevel release, but 
I don't see the case for a major version number step.  Those should IMHO 
be reserved for user-visible, _incomptabible_ changes.  I.e. as long as 
basically all scripts written for version 4.0 (or maybe 4.4) still work, 
I don't quite see a reason to bump to 5.0.

HBB

Re: old tex files in repository

[Mojca M. <moj...@gm...>]

On Mon, Sep 12, 2011 at 09:09, Mojca Miklavec wrote:
> On Sun, Sep 11, 2011 at 18:41, Ethan Merritt wrote:
>> On Sunday, 11 September 2011, Mojca Miklavec wrote:
>>>
>>> Should gnuplot-lua-tikz.sty be removed from CVS (if it is
>>> auto-generated)?
>>
>> See above.  It was removed from CVS long ago.
>
> Mea culpa. (I'm very sorry.)
>
> I hate CVS so much that I use the repository converted into git:
>    https://github.com/gnuplot/gnuplot/
> I'm using
>    git cvsimport -C $PWD/git/gnuplot.git -p x -d $PWD/cvs/gnuplot gnuplot
> inside a cron job and it seems that the command "forgot" to remove some files.

I think that I found the culprit. When running "rsync", I forgot to
use the "--delete" switch. In 99.9 % cases this is not needed since
files are not deleted from repository on daily basis, but it did
matter in this particular case.

I will fix this and create a new repository on github, with fixed history.

Mojca

Re: adding picins.sty to docs/

[Allin C. <cot...@wf...>]

On Mon, 12 Sep 2011, Mojca Miklavec wrote:

> It is not about skills needed to install picins.sty. [...]
>
> It is about the ability to make compilation work out-of-the-box.

I guess the problem here is that picins.sty is a rather 
ancient LaTeX file -- designed for the old LaTeX 2.09 and last 
revised in 1992. It's available on CTAN but may not be 
included in some modern packagings of TeX/LaTeX -- or at least 
may be in some relatively hard-to-find auxiliary package.
I can see a case for including a copy in the gnuplot sources.

Allin Cottrell

Re: How to generate <ul> & <li> or \begin{itemize} in documentation?

[Mojca M. <moj...@gm...>]

On Sun, Sep 11, 2011 at 22:47, Ethan A Merritt wrote:
> On Sunday, 11 September 2011, Mojca Miklavec wrote:
>> Dear list,
>>
>> What is the syntax in help for terminals that would generate
>> <ul><li>...</li>...</ul> syntax in HTML output, \begin{itemize} in
>> LaTeX (PDF documentation) and a normal "-" in text mode?
>
> .../docs/README  explains the format of gnuplot.doc
> But there is no provision for bulleted lists.  I agree with you that
> it would be useful, but it would have to be added to all of the
> various doc2XXX.c conversion programs.

I now rewrote term_help, so that it doesn't need bullets any more.

But I can take a look into coding this if there is interest.

>> Also, how could one replace TeX with \TeX in gnuplot.tex that is used
>> to generate gnuplot.doc?
>
> ??
> That's backwards.

I'm sorry. I meant "that is used to generate gnuplot.pdf".

> gnuplot.doc is used to generate gnuplot.tex.
> I suppose you could add a search-and-replace filter in doc2tex.c,

That would probably be an overkill. I guess that *.el scripts are
written in lisp for exactly the same reason: to complex to code in
plain C.

> but it would probably be simpler to run sed 's/ TeX/ \\TeX/' on
> the output. You could add it as an extra line in the Makefile rule
> for gnuplot.tex

That probably makes more sense. I will try if I can figure out how and
where to apply this. I will ask again if I will need help.

Mojca

Re: adding picins.sty to docs/

[Mojca M. <moj...@gm...>]

On Sun, Sep 11, 2011 at 18:51, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Sunday, 11 September 2011, Mojca Miklavec wrote:
>>
>> Would it be possible to put picins.sty to docs/, so that documentation
>> (pdffigures) will at least compile without problems?
>
> On the other hand, it's not that hard to regenerate a copy of the
> pdf+figures from the CVS source yourself.   It is true that you may
> have to tweak the local TeX environment to successfully use the
> "make pdffigures" target rather than "make pdf".  But you clearly have
> far more TeX experience than I do, so it seems surprising that you
> would have difficulty installing one extra *.sty file on your system.

It is not about skills needed to install picins.sty. (One could
probably also compile gnuplot with manual calls to gcc, without having
to use ./configure etc.)

It is about the ability to make compilation work out-of-the-box. The
file is so small that I don't see any harm in including it (just
placing a copy to <repository>/docs/picins.sty). Trivial patches add
up. I can easily imagine that linux distributions would prefer to
build gnuplot with "make pdffigures", but they won't if they have to
patch sources.

Mojca

Re: old tex files in repository

[Mojca M. <moj...@gm...>]

On Sun, Sep 11, 2011 at 18:41, Ethan Merritt wrote:
> On Sunday, 11 September 2011, Mojca Miklavec wrote:
>>
>> Should gnuplot-lua-tikz.sty be removed from CVS (if it is
>> auto-generated)?
>
> See above.  It was removed from CVS long ago.

Mea culpa. (I'm very sorry.)

I hate CVS so much that I use the repository converted into git:
    https://github.com/gnuplot/gnuplot/
I'm using
    git cvsimport -C $PWD/git/gnuplot.git -p x -d $PWD/cvs/gnuplot gnuplot
inside a cron job and it seems that the command "forgot" to remove some files.

In 99.9% of cases it works perfectly fine, but it seems that in this
case it didn't do the job properly. I will try to inspect why this
happens. It could be a bug in git or something unexpected that I did
at my side.

Somebody else's clone doesn't seem to suffer from this
(https://github.com/Reen/gnuplot/tree/master/share/LaTeX). The irony
is that I'm also using a clone of his repository, but in that one I
messed with inclusion of TikZ myself, so that this particular file
remained there as a consequence of my own commits.

Thank you for pointing this out and sorry for asking about things that
were wrong at my end.

>> Why is pdffigures.tex included in CVS if it is built during "make pdf" anyway?
>
> The comment you quote attempts to explain this.
> The top-level file titlepag.tex contains a line
> \include{pdffigures}
> In order to toggle whether or not the figure-generation code is
> _really_ used, the Makefile either creates appropriate file contents
> for pdffigures.tex or creates an empty file with that name.
>
> Perhaps someone more knowledgeable in TeX syntax knows how make the
> latex "\include" statement conditional on some external variable,
> which would be an alternative way to accomplish the same thing.

Please try the following:


\documentclass{article}

\begin{document}

\ifx\printmode\undefined
	{document without figures}
	\write16{NOOOOOOOOOO}
\else
	{this document has figures}
	\write16{YEEEEEEEEES}
\fi

\end{document}

You can then compile it with
    pdflatex "\\def\\printmode{$SOMEVARIABLE}\\input{filename.tex}"
or simply with
    pdflatex '\def\\printmode{figures}\input{filename.tex}'
when you want figures and with
    pdflatex filename.tex
when you don't. Note that the code above only tests if the command
sequence has been defined, so figures will be generated no matter what
you put into $SOMEVARIABLE. You could also compare contents, but in
this case there is no need to do so in this particular case (it would
be bad if you required to use the complicated sequence to compile the
default document).


In practice you could replace
    \include{pdffigures}
with
    \ifx\printmode\undefined\else
        \usepackage{graphicx}
        \usepackage{picins}
    \fi
and then call
    pdflatex '\def\printmode{figures}\input{gnuplot.tex}'


Alternatively you could create gnuplot-figures.tex with
    \def\printmode{figures}
    \input gnuplot.tex
and compile with
    pdflatex gnuplot-figures.tex
instead of
    pdflatex '\def\\printmode{figures}\input{gnuplot.tex}'
This would of course give you gnuplot-figures.tex.

Mojca

Release plans: Version 4.4.4 and beyond

[sfeam (E. Merritt) <eam...@gm...>]

Version 4.4.4
=============

My plan is to release version 4.4.4 some time in the next month,
consistent with the ~6 month release cycle that has held throughout
the 4.2 and 4.4 release series.  NEWS entries for 4.4.4 include

* NEW boxxyerrors plot style now allows variable color
* NEW splot with pm3d now allows variable rgb color
* NEW "nonuniform matrix" indicates ascii data with explicit x, y
* CHANGE columnhead(N) is a string-valued function, not a keyword
* CHANGE Demarcate plots in svg output using <g id="Plot_#"><title>...
* CHANGE xticlabels() works for binary data files as well as ascii
* CHANGE "set key maxrows" now applies to 3D plots as well as 2D
* CHANGE rewrite installation path rules for TeX files
* FIX wxt terminal should now work on at least some flavors of OSX
* FIX incorrect space allowed for outside left key box
* FIX buffer overflow from enhanced text timefmt tic labels
* FIX correction for offset in epochs when reading in time format "%s"
* FIX discontinuity in defined palette limited by maxcolors
* FIX initialization of svg pattern-fill definitions
* FIX positioning of histogram bars when some data entries are missing
* FIX emf terminal can handle UTF-8 encoding

My thought is that 4.4.4 will probably be the last release in the
4.4 series.  Of course we can re-think that if significant issues
arise in the next 6 months.

Beyond
======

After releasing 4.4.4, I am thinking that we should re-tag the CVS
tree as the development branch for gnuplot version 5 and plan to
put out a version 5.0 release candidate sometime after the New Year,
aiming for a full release in the Spring.

The chief arguments I see for bumping the version to 5 
(rather than 4.6):

1) The code in the development branch has diverged enough from the 
code in the version 4 branch that most new patches cannot be easily
back-ported.

2) There are significant syntax and UI changes already in or queued for
the development branch, notably
- block-structured if/else/do/for/while statements
- nested iteration 
- local customization of linetypes using "set linetype"
- tab completion and UTF-8 support in the builtin readline
- reworked Windows driver
- "stats" subsystem (Patchset #2894333)

and probably more I'm not thinking of at the moment.

What do you think?