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

Re: exist, configure, doc2tex and \index

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

>> 2. Gnuplot supports both exists('a') and exist('a'), but documents
>> only one of them. As it was me who made this confusion, I would
>> propose to keep only exist('a').
>
> I would rather allow the extra 's' since it is more natural in
> English.  Do you really care about 1 extra character in the source code?

I see votes for exists('a'). Thus exist('a') could be removed or be 
documented in gnuplot.doc (functions do not allow abbreviations).

Further:
gnuplot> print words(4)
          internal error : non-STRING argument

gnuplot> print exists(4)
0


Shouldn't we expect the same error message?
(and "internal error: ...", not "... error : ...")

---
PM

Re: exist, configure, doc2tex and \index

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

>> 3. doc2tex.c produces the following in the .tex file:
>>
>> as you see, there appears "up" keyword in the index, and similar. See the
>> code in doc2tex.c, below line:
>>  	/* Make the final word an index entry also */
>> I propose to keep the whole word including "-" and "_".
>
> OK for '-', but '_' may need closer inspections.  People have abused '_'
> to tweak multi-word index entries and help nodes in somewhat random ways
> for a while now.

I've replaced _ by space, by not -. The index is improved.

There are some items that could be cleaned-up in gnuplot.doc (replace _ and 
- by space), but I would let it to an English native:

 	Seeking-assistance vs Seeking assistance
 	user-defined
 	grid_data
 	error_estimates
 	command-line-editing
 	command-line-options
 	multi-branch vs multi branch

--
PM

Re: exist, configure, doc2tex and \index

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

Hans-Bernhard Br=F6ker wrote:
> Petr Mikulik wrote:
>=20
>>Few minor things:
>>
>>1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now? W=
on't=20
>>be "nice" for 4.2.
>=20
>=20
> It would be even less nice to lie about the maturity of those options.=20
> Yes, those features are experimental, and they should be marked as such.
>=20
>=20
>>2. Gnuplot supports both exists('a') and exist('a'), but documents only=
 one=20
>>of them. As it was me who made this confusion, I would propose to keep =
only=20
>>exist('a').

Not sure if matching with Octave is that important.  The more grammatical=
ly correct syntax would probably be "exists('a')", because the argument i=
s always singular.  In the case of Octave, the contents could be plural, =
i.e., an array.

Both is fine, but it is usually good to not have functions with nearly id=
entical syntax.  I see there is a "word" and "words" which aren't the sam=
e, in this case the function is a noun as opposed to a verb tense.  Not t=
oo concerned, but you can see where a tad of confusion could arise from e=
xist, exists, word, words.

BTW, this help entry is not very good:

gnuplot> help show functions
 The `show functions` command lists all user-defined functions and their
 definitions.

 Syntax:
       show functions

 For information about the definition and usage of functions in `gnuplot`=
,
 please see `expressions`.
 See also
 splines as user defined functions (spline.dem)
 and
 use of functions and complex variables for airfoils (airfoil.dem).

First, if we want to stay with this, could the visual formatting be a lit=
tle nicer?  I.e.,

 please see `expressions`.

 See also
      splines as user defined functions (spline.dem)
 and
      use of functions and complex variables for airfoils (airfoil.dem).

Second, it should really be "see `expressions functions`".

Third, do we really need to refer to spline.dem (there is no help entry "=
splines as user defined functions") or airfoil.dem (there is no help entr=
y "user of functions...")?  There are many other demos that use functions=
 now I'm guessing.

Fourth, if we want to keep those references, why would there need to be r=
eturns in the sentence?  Couldn't it just be inline "See also spline.dem =
for examples of user-defined functions or airfoil.dem for examples of fun=
ctions and complex variables."?


> OK for '-', but '_' may need closer inspections.  People have abused '_=
'=20
> to tweak multi-word index entries and help nodes in somewhat random way=
s=20
> for a while now.  I really don't think we need stuff like plot_datafile=
=20
> as an index entry.

Yes, I'm not a fan of the underscores as a help index.  In fact, we may a=
t some point be able to just drop the underscore and leave it as "plot da=
tafile" if there is no ambiguity.

Dan

Re: exist, configure, doc2tex and \index

[<br...@ph...>]

Petr Mikulik wrote:
> Few minor things:
> 
> 1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now? Won't 
> be "nice" for 4.2.

It would be even less nice to lie about the maturity of those options. 
Yes, those features are experimental, and they should be marked as such.

> 2. Gnuplot supports both exists('a') and exist('a'), but documents only one 
> of them. As it was me who made this confusion, I would propose to keep only 
> exist('a').

This would have been a much better idea a couple of weeks ago than it is 
now.  I'm afraid I have to object to changing the syntax this shortly 
before the release.

> 3. doc2tex.c produces the following in the .tex file:
> 
> (see {\bf start-up (p.~\pageref{start-up})\index{up}}) and, of course,
>  	by later explicit changes.
> see {\bf mouse variables (p.~\pageref{mouse variables})\index{variables}}
>  	for details.
> See {\bf fit error\_estimates (p.~\pageref{fit error_estimates})\index{estimates}}.
> 
> as you see, there appears "up" keyword in the index, and similar. See the 
> code in doc2tex.c, below line:
>  	/* Make the final word an index entry also */
> I propose to keep the whole word including "-" and "_".

OK for '-', but '_' may need closer inspections.  People have abused '_' 
to tweak multi-word index entries and help nodes in somewhat random ways 
for a while now.  I really don't think we need stuff like plot_datafile 
as an index entry.

Re: exist, configure, doc2tex and \index

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

On Friday 11 August 2006 03:14 pm, you wrote:
> >> 1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now?
> >> Won't be "nice" for 4.2.
>
>    Enable command line macros (EXPERIMENTAL)
>    Enable placement of rectangles and other objects (EXPERIMENTAL)
>    Enable plot style image (EXPERIMENTAL)
>    Enable general binary data file reading (EXPERIMENTAL)
>    Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
>    Enable wxWidgets interactive terminal (EXPERIMENTAL)

Sorry, I misunderstood.  I thought you meant that "strings" should
no longer be experimental - and they aren't.

These remaining ones I really do consider to be experimental,
except maybe for the wxWidgets terminal.  I would not expect everyone
to choose to include them.  The wxWidgets terminal requires a large 
collection of very recent support libraries, and again many people may
not include it.

> If we keep both exists() and exist(), they should be mentioned in the docs
> (help exist, help exists)

To the user it is just like any other shorthand form. I would have written the
test     if (almost_equals(c_token, "exist$s"))
except that the parsing code doesn't use almost_equals().

Re: exist, configure, doc2tex and \index

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

Petr Mikulik wrote:
>>>1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now?
>>>Won't be "nice" for 4.2.
>>
>>Are you sure you are looking at the current source?
>>That EXPERIMENTAL marking was removed 12 June 2006.
> 
> 
> There are still the following:
> 
>    Enable command line macros (EXPERIMENTAL)
>    Enable placement of rectangles and other objects (EXPERIMENTAL)
>    Enable plot style image (EXPERIMENTAL)
>    Enable general binary data file reading (EXPERIMENTAL)
>    Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
>    Enable wxWidgets interactive terminal (EXPERIMENTAL)

I would be fine with leaving those in.  To me, "experimental" means it is new and works for the most part but once mass use occurs there may be some adjustments; say there is some unforseen conflict of syntax.

Is that a position to take on new items?  I.e., we tried hard to avoid syntax changes, but with experimental items that likelihood may be slightly higher.

Dan

Re: exist, configure, doc2tex and \index

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

>> 1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now?
>> Won't be "nice" for 4.2.
>
> Are you sure you are looking at the current source?
> That EXPERIMENTAL marking was removed 12 June 2006.

There are still the following:

   Enable command line macros (EXPERIMENTAL)
   Enable placement of rectangles and other objects (EXPERIMENTAL)
   Enable plot style image (EXPERIMENTAL)
   Enable general binary data file reading (EXPERIMENTAL)
   Enable X11 polygon info in binary, not ascii (EXPERIMENTAL)
   Enable wxWidgets interactive terminal (EXPERIMENTAL)

>> 2. Gnuplot supports both exists('a') and exist('a'), but documents
>> only one of them. As it was me who made this confusion, I would
>> propose to keep only exist('a').
>
> I would rather allow the extra 's' since it is more natural in
> English.  Do you really care about 1 extra character in the source code?

The idea was to have the same name as in Octave.
If we keep both exists() and exist(), they should be mentioned in the docs 
(help exist, help exists)

---
PM

Re: exist, configure, doc2tex and \index

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

On Friday 11 August 2006 01:46 pm, Petr Mikulik wrote:
> Few minor things:
>
> 1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now?
> Won't be "nice" for 4.2.

Are you sure you are looking at the current source?
That EXPERIMENTAL marking was removed 12 June 2006.

> 2. Gnuplot supports both exists('a') and exist('a'), but documents
> only one of them. As it was me who made this confusion, I would
> propose to keep only exist('a').

I would rather allow the extra 's' since it is more natural in
English.  Do you really care about 1 extra character in the source code?

> 3. doc2tex.c produces the following in the .tex file:
>
> (see {\bf start-up (p.~\pageref{start-up})\index{up}}) and, of
> course, by later explicit changes.
> see {\bf mouse variables (p.~\pageref{mouse
> variables})\index{variables}} for details.
> See {\bf fit error\_estimates (p.~\pageref{fit
> error_estimates})\index{estimates}}.
>
> as you see, there appears "up" keyword in the index, and similar. See
> the code in doc2tex.c, below line:
>  	/* Make the final word an index entry also */
> I propose to keep the whole word including "-" and "_".

I suppose that is reasonable.

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

Re: GNUPLOT_PS_DIR problem [was Re: the next release]

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

Ethan Merritt wrote:
> (2) Whatever build environment you are using fails to=20
>     #include "PostScript/prologues.h"
>     when building the postscript terminal.
>
> Please find the following line in post.trm:
>
>   #if defined(_Windows)
>   # include "win/winmain.h"
>   #elif defined(OS2)
>   # define INCL_DOSPROCESS
>   # define INCL_DOSMODULEMGR
>   # include <os2.h>
>  =20
>>> #elif !defined(GNUPLOT_PS_DIR)
>>>      =20
>   #  include "PostScript/prologues.h"
>   #endif
>
> And try changing it to
>
>   #if defined(_Windows)
>   # include "win/winmain.h"
>   #elif defined(OS2)
>   # define INCL_DOSPROCESS
>   # define INCL_DOSMODULEMGR
>   # include <os2.h>
>  =20
>>> #endif
>>> #if !defined(GNUPLOT_PS_DIR)
>>>      =20
>   #  include "PostScript/prologues.h"
>   #endif
>
> I think that will work, but whether or not it is truly
> the correct fix is another question.
>  =20
Oh yes, you're right, there was a problem here. Your fix is correct, but=20
we can also avoid to include the headers altogether when using the=20
internal headers :

#if defined(GNUPLOT_PS_DIR)
# if defined(_Windows)
#  include "win/winmain.h"
# elif defined(OS2)
#  define INCL_DOSPROCESS
#  define INCL_DOSMODULEMGR
#  include <os2.h>
# endif
#else
# include "PostScript/prologues.h"
#endif


Best regards,

Timoth=E9e

GNUPLOT_PS_DIR problem [was Re: the next release]

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

I'll cc this to Thimotee Lecompte, who I think is most on top
of the issue.


On Friday 11 August 2006 01:59 pm, BBands <bb...@ya...> wrote:
> Hi Ethan,
>
> I downloaded current cvs to help check the upcoming
> release. I get some new errors that I suspect are
> related to the ps headers???
>
> ..\\term\post.trm(3182) : error C2065:
> 'prologue_8859_15_ps' : undeclared identifier

So far as I can tell from the code, this means that

(1) You are building a built-in set of PostScript prologue
    scripts, which is not really intended to be the default
    on any platform.  (I think, although I keep on being
    confused about the state of things on Windows). 
    Nevertheless, that is supposed to work.

(2) Whatever build environment you are using fails to 
    #include "PostScript/prologues.h"
    when building the postscript terminal.

Please find the following line in post.trm:

  #if defined(_Windows)
  # include "win/winmain.h"
  #elif defined(OS2)
  # define INCL_DOSPROCESS
  # define INCL_DOSMODULEMGR
  # include <os2.h>
>>#elif !defined(GNUPLOT_PS_DIR)
  #  include "PostScript/prologues.h"
  #endif

And try changing it to

  #if defined(_Windows)
  # include "win/winmain.h"
  #elif defined(OS2)
  # define INCL_DOSPROCESS
  # define INCL_DOSMODULEMGR
  # include <os2.h>
>>#endif
>>#if !defined(GNUPLOT_PS_DIR)
  #  include "PostScript/prologues.h"
  #endif

I think that will work, but whether or not it is truly
the correct fix is another question.


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

exist, configure, doc2tex and \index

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

Few minor things:

1. In ./configure, shouldn't strings "(EXPERIMENTAL)" be removed now? Won't 
be "nice" for 4.2.

2. Gnuplot supports both exists('a') and exist('a'), but documents only one 
of them. As it was me who made this confusion, I would propose to keep only 
exist('a').

3. doc2tex.c produces the following in the .tex file:

(see {\bf start-up (p.~\pageref{start-up})\index{up}}) and, of course,
 	by later explicit changes.
see {\bf mouse variables (p.~\pageref{mouse variables})\index{variables}}
 	for details.
See {\bf fit error\_estimates (p.~\pageref{fit error_estimates})\index{estimates}}.

as you see, there appears "up" keyword in the index, and similar. See the 
code in doc2tex.c, below line:
 	/* Make the final word an index entry also */
I propose to keep the whole word including "-" and "_".
Any idea?

---
PM

Re: What's left for 4.2?

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

>
>> What's left to do before packaging up 4.2?
>> Nothing.
>>
>> Let's go for it.
>
> Sounds good.  Summer is winding down.

Fine with me.

Let's go for freeze and beta1.

---
PM

Re: What's left for 4.2?

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

Ethan Merritt wrote:

> What's left to do before packaging up 4.2?
> Nothing.
> 
> Let's go for it.

Sounds good.  Summer is winding down.

Dan

What's left for 4.2?

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

On Thursday 10 August 2006 12:19 pm, Timoth=C3=A9e Lecomte wrote:
> Timoth=C3=A9e Lecomte wrote:

> - why isn't faq.tex in gnuplot/docs and part of gnuplot distribution ?

Well, one possible answer is to avoid the chicken-and-egg problem
of getting all the files ready for a release. We don't want to package
a release until the files are in a final version, but the FAQ cannot
reach its final state until the release is prepared.  At least, not if
it is to contain information about the actual release.

> Ethan, a small update on "what's left for 4.2" maybe ?

Sure.

What's left to do before packaging up 4.2?
Nothing.

Let's go for it.

The FAQ can be updated in parallel, and finalized right after the
release is err.. released.

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

Re: Gnuplot FAQ and beta release

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

> I was going to work on updating some points in the gnuplot FAQ (svg 
> software, gd formats for 4.2, etc.) when I saw that the FAQ is in a 
> different directory in the cvs. Then I started to ask myself a couple of 
> questions :
>
> - can I work on faq.tex with gnuplot 4.2 in mind ?

Yes, great idea!

Hints:
- 7.8 could mention "exit gnuplot"
- 7.10 could reference 7.4

> - why isn't faq.tex in gnuplot/docs and part of gnuplot distribution ?

Some traditional reasons?
If we continue: faq-ja.tex should also go from gnuplot/docs into faq/.

---
PM

Re: Gnuplot FAQ and beta release

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

Timoth=C3=A9e Lecomte wrote:
> Hi,
>
> I was going to work on updating some points in the gnuplot FAQ

Oops. I forgot to remove the "and beta release" part of the title. I=20
don't know what I wanted to say...
Ethan, a small update on "what's left for 4.2" maybe ?

Timoth=C3=A9e

Gnuplot FAQ and beta release

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

Hi,

I was going to work on updating some points in the gnuplot FAQ (svg=20
software, gd formats for 4.2, etc.) when I saw that the FAQ is in a=20
different directory in the cvs. Then I started to ask myself a couple of=20
questions :

- can I work on faq.tex with gnuplot 4.2 in mind ?
- why isn't faq.tex in gnuplot/docs and part of gnuplot distribution ?

I hope you can guide me on these points.

Best regards,

Timoth=C3=A9e

How exactly to handle point sizes?

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

Hello,

I don't understand how exactly the terminal should handle pointsize.
README says:

  There is a global variable 'pointsize' which is controlled by the
  set pointsize command. If possible, use that. pointsize should be
  examined at terminal init. If it is subsequently changed, the
  pointsize() function will be called.

But what exactly does that mean? Suppose that someone says

set pointsize 5
plot sin(x) with points ps 3

Should the resulting line be 3 or 15 units wide (PS draws 3, windows
draws 15)? The very weird part is that gnuplot sets the pointsize at
the end of plot to the "set pointsize" value. I thought that "set
pointsize X" is only a scaling factor, not a default option passed to
"with points ps X"

Result - if I do this with the windows terminal:
   set pointsize 5
   plot sin(x) with points
then I get points that are 25 units big (windows interprets 5 as
scaling factor and then multiplies the point size with 5 since gnuplot
sets that the pointsize to 5 explicitely). Is this normal?
   plot sin(x) with points ps 1
will plot them 5 units big, but I wonder if 25 units is OK.

PostScript doesn't care about setting that value at the beginning, so
   set pointsize 5
   plot sin(x) with points ps 1
will create points which are exactly one unit big, but
   set pointsize 5
   plot sin(x) with points
is 5 units. According to my understanding the first example should
give 5 units as well. I understand "set pointsize" being a scaling
factor for any point size mentioned later, but the behavior in
different terminals is pretty confusing anyway.

Thanks for explanation,
    Mojca

Re: [Gnuplot-cvs] CVS Update: gnuplot

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

Hans-Bernhard Br=F6ker wrote:
> Timoth=E9e Lecomte wrote:
>  =20
>> CVSROOT:	/cvsroot/gnuplot
>> Module name:	gnuplot
>> Repository:	./
>> Changes by:	tle...@sc....(none)	06/08/06 19:00=
:56
>>
>> Modified files:
>> 	./: ChangeLog INSTALL configure.in=20
>>
>> Log message:
>> 	Remove detection of libpng, useless since the png driver has been rem=
oved.
>>    =20
>
> Thimo, are you *sure* this is a good idea?  Are you sure there's no=20
> supported platform where libpng has to be searched and found for GD to=20
> compile?
>  =20
I took some time before doing this and I think it's ok. Let me explain :

To compile GD itself, sure, libpng has to be searched for. Not only=20
libpng, but also zlib and libjpeg (note that gnuplot's ./configure=20
doesn't do anything for libjpeg).

Then, the code that I removed was really doing _nothing_.

    libpng_CPPFLAGS was defined but never appended to CPPFLAGS, nor=20
exported for automake.
    libpng_LDFLAGS was defined but never appended to LDFLAGS, nor=20
exported for automake.
    HAVE_LIBPNG was defined but not used anywhere in the code since the=20
standalone png driver has been removed.

There was a step to check for the libpng version, but that's not=20
gnuplot's problem, it gd's problem.

Actually, I'm tempted to remove the test for zlib too, because it's gd's=20
problem too. The only problem when removing that one is when an old=20
version of gd (which doesn't have gdlib-config) is used.

Thanks for asking !

Best regards,

Timoth=E9e

Re: change in handling missing data.

[<br...@ph...>]

Dmitri A. Sergatskov wrote:
> Here is the data file ("t3.dat"):
> # -- begin
> 0 2
> 2 0
> NaN NaN
> 4 2
> 2 4
> # -- end

I think one important question here has been entirely overlooked. 
Dmitri, you said that this was *octave* writing this data file to be 
used by gnuplot, right?  Well, here's the question: why is octave 
writing numerical garbage into its output, and why should gnuplot be the 
place to worry about that?

Re: [Gnuplot-cvs] CVS Update: gnuplot

[<br...@ph...>]

Timoth=E9e Lecomte wrote:
> CVSROOT:=09/cvsroot/gnuplot
> Module name:=09gnuplot
> Repository:=09./
> Changes by:=09t...@sc....(none)=0906/08/0=
6 19:00:56
>=20
> Modified files:
> =09./: ChangeLog INSTALL configure.in=20
>=20
> Log message:
> =09Remove detection of libpng, useless since the png driver has bee=
n removed.

Thimo, are you *sure* this is a good idea?  Are you sure there's no=
=20
supported platform where libpng has to be searched and found for GD t=
o=20
compile?

Re: change in handling missing data.

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

Ethan A Merritt wrote:

> plot "t.dat" using 1:2
> ======================
> Each sample counts as 0.01 seconds.
>   %   cumulative   self              self     total
>  time   seconds   seconds    calls   s/call   s/call  name
>  27.98      2.37     2.37  1000000     0.00     0.00  store2d_point
>  20.19      4.08     1.71  1000000     0.00     0.00  df_tokenise
>  15.23      5.37     1.29  1000041     0.00     0.00  PS_vector
>  13.70      6.53     1.16  1000001     0.00     0.00  df_readascii
>  10.15      7.39     0.86  1000001     0.00     0.00  df_gets
>   7.79      8.05     0.66        1     0.66     1.99  plot_lines
>   2.01      8.22     0.17        1     0.17     6.44  get_data
>   0.83      8.29     0.07  2000000     0.00     0.00  gp_strtod
>   0.59      8.34     0.05  2000000     0.00     0.00  check_missing
>   0.59      8.39     0.05  1000001     0.00     0.00  df_readline
>  
> plot "t.dat" using $1:$2
> ========================
> Each sample counts as 0.01 seconds.
>   %   cumulative   self              self     total
>  time   seconds   seconds    calls   s/call   s/call  name
>  20.97      2.65     2.65  1000000     0.00     0.00  df_tokenise
>  19.46      5.11     2.46  1000000     0.00     0.00  store2d_point
>  15.51      7.07     1.96  1000001     0.00     0.00  df_readascii
>   9.18      8.23     1.16  1000041     0.00     0.00  PS_vector
>   8.23      9.27     1.04  1000001     0.00     0.00  df_gets
>   5.66      9.99     0.72  2000002     0.00     0.00  evaluate_at
>   4.67     10.58     0.59        1     0.59     1.78  plot_lines
>   2.85     10.94     0.36        1     0.36    10.70  get_data
>   1.78     11.16     0.23  2000000     0.00     0.00  f_dollars
>   1.62     11.37     0.21  2000002     0.00     0.00  execute_at
>   1.50     11.56     0.19  2000002     0.00     0.00  push
>   1.27     11.72     0.16  2000002     0.00     0.00  pop
>   1.27     11.88     0.16  2000000     0.00     0.00  check_missing
>   1.11     12.02     0.14  4000000     0.00     0.00  real
>   1.03     12.15     0.13  1000001     0.00     0.00  df_readline
>   0.87     12.26     0.11  2000057     0.00     0.00  Gcomplex
>   0.71     12.35     0.09  2000000     0.00     0.00  gp_strtod
>   0.55     12.42     0.07  2000002     0.00     0.00  check_stack
>   0.36     12.46     0.05                             df_determine_matrix_info
>   0.32     12.50     0.04                             more_on_stack
>   0.24     12.53     0.03  2000002     0.00     0.00  reset_stack
> 
> As Daniel said, the extra time is due to the overhead of
> evaluating each coordinate as an expression rather than as a constant.
> ( evaluate_at f_dollars push pop check_stack reset_stack )

I would have thought that evaluate_at or execute_at would have been where the increase is,  but that doesn't appear to be much in either case.  I would say PS_vector would be the same amount of CPU in both cases.  In the first case it is 15% in the second 9%.  That would mean 0.15 Total_1 = 0.9 Total_2, or Total_2 = 1.67 Total_1.  Is my thinking correct on that?  So a 67% increase in CPU consumption?

> I don't see any horrible time-wasters in the profile, even when I break
> it down to individual lines of code.  However, I still don't know which
> bit, exactly, is being accounted for as "system time". Perhaps there
> is some system call we can manage to do with out, but at present I
> can't think what it would be.

Good question.  evaluate_at, execute_at, push, pop, real, Gcomplex, check_stack, more_on_stack, and reset_stack don't appear to have an system calls.  df_determine_matrix_info has an "fseek" which is something that could be a potential time waster, however gprof doesn't indicate that being called 1 million times.

I'm not sure why df_determine_matrix_info is called in one case over the other, but what is peculiar is that gprof doesn't have anythingthing listed under the number of calls for df_determine_matrix_info or more_on_stack.

Dan

Re: change in handling missing data.

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

On Monday 07 August 2006 12:44 am, Dmitri A. Sergatskov wrote:
> On 8/7/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
> > On Sunday 06 August 2006 10:07 pm, Dmitri A. Sergatskov wrote:

> > For plot "t.dat" using ($1):($2)
> > 4.456u 2.342s 0:06.79 100.0%    0+0k 0+0io 0pf+0w
> >
> > > I did multiple passes, so I am pretty sure the data file is in disk cache.
> > > All this is on FedoraCore 5/ Pentiun4 2.6GHz / 2GB of RAM
> >
> > So it runs faster on my machine, but yes it spends more time on the second test.
> 
> I am surprised that the difference is so large. I tried running both
> hyperthreaded and non-hyperthreaded and it is pretty much the same.
> My file is available at
> ftp://coffee.phys.unm.edu/pub/dima/incoming/t-das.dat.bz2

I get the same timings as before if I use your input data file.
Benchmark script
  set term post
  set output '/dev/null'
  plot "t-das.dat" using 1:2 with lines
Timing
  2.728u 0.133s 0:02.86 99.6%     0+0k 0+0io 0pf+0w

Same with
  plot "t-das.dat" using ($1):($2) with lines
Timing
  4.479u 2.295s 0:06.77 99.8%     0+0k 0+0io 0pf+0w

System info
-----------
lascaux [188] uname -a
Linux lascaux 2.6.12-24mdksmp #1 SMP Mon Jul 17 12:46:00 MDT 2006 
         i686 Intel(R) Pentium(R) 4 CPU 2.60GHz unknown GNU/Linux
lascaux [189] head -1 /proc/meminfo
MemTotal:       514176 kB

gcc version 4.0.1 
CFLAGS = -Wall -g  -O

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

Re: change in handling missing data.

[Dmitri A. S. <das...@gm...>]

On 8/7/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
> On Sunday 06 August 2006 10:07 pm, Dmitri A. Sergatskov wrote:
...
>
> For plot "t.dat" using ($1):($2)
> 4.456u 2.342s 0:06.79 100.0%    0+0k 0+0io 0pf+0w
>
> > I did multiple passes, so I am pretty sure the data file is in disk cache.
> > All this is on FedoraCore 5/ Pentiun4 2.6GHz / 2GB of RAM
>
> So it runs faster on my machine, but yes it spends more time on the second test.

I am surprised that the difference is so large. I tried running both
hyperthreaded and non-hyperthreaded and it is pretty much the same.
May be the data format matters?

My file is available at
ftp://coffee.phys.unm.edu/pub/dima/incoming/t-das.dat.bz2

(it is 11 Meg)

You can drop off yours to there as well.

I've also tried GNU time (/usr/bin/time, instead of using
built-in bash time); it gives slightly more info, and the only big
difference I've noticed was:

(plot w/o using):

Involuntary context switches: 452

(plot with using ($1):($2))

Involuntary context switches: 1165

Perhaps evaluation of a token trashes the CPU cache ...

> --
> Ethan A Merritt
>

Sincerely,

Dmitri.
--

Re: change in handling missing data.

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

On Sunday 06 August 2006 10:07 pm, Dmitri A. Sergatskov wrote:
> For the benchamrk I made 2 column data file
> x = (-10,10), y = sin(x)
> with 1e6 (one million) rows.
> 
> plot "t.dat" using 1:2
> 
> [dima@das200 tmp]$ time gnuplot < cmd
> 
> real    0m3.831s
> user    0m3.528s
> sys     0m0.176s
> 
> plot "t.dat" using ($1):($2)
> 
> [dima@das200 tmp]$ time gnuplot < cmd
> 
> real    0m11.086s
> user    0m5.828s
> sys     0m4.600s

OK, I can confirm that to some extent.
Benchmarked on a hyperthreaded P4 at 2.6GHz
(I used  set term post; set output '/dev/null')

For  plot "t.dat" using 1:2
2.665u 0.094s 0:02.75 100.0%    0+0k 0+0io 0pf+0w

For plot "t.dat" using ($1):($2) 
4.456u 2.342s 0:06.79 100.0%    0+0k 0+0io 0pf+0w

> I did multiple passes, so I am pretty sure the data file is in disk cache. 
> All this is on FedoraCore 5/ Pentiun4 2.6GHz / 2GB of RAM

So it runs faster on my machine, but yes it spends more time on the second test.
Here are the gprof outputs:

plot "t.dat" using 1:2
======================
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 27.98      2.37     2.37  1000000     0.00     0.00  store2d_point
 20.19      4.08     1.71  1000000     0.00     0.00  df_tokenise
 15.23      5.37     1.29  1000041     0.00     0.00  PS_vector
 13.70      6.53     1.16  1000001     0.00     0.00  df_readascii
 10.15      7.39     0.86  1000001     0.00     0.00  df_gets
  7.79      8.05     0.66        1     0.66     1.99  plot_lines
  2.01      8.22     0.17        1     0.17     6.44  get_data
  0.83      8.29     0.07  2000000     0.00     0.00  gp_strtod
  0.59      8.34     0.05  2000000     0.00     0.00  check_missing
  0.59      8.39     0.05  1000001     0.00     0.00  df_readline
 
plot "t.dat" using $1:$2
========================
Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total
 time   seconds   seconds    calls   s/call   s/call  name
 20.97      2.65     2.65  1000000     0.00     0.00  df_tokenise
 19.46      5.11     2.46  1000000     0.00     0.00  store2d_point
 15.51      7.07     1.96  1000001     0.00     0.00  df_readascii
  9.18      8.23     1.16  1000041     0.00     0.00  PS_vector
  8.23      9.27     1.04  1000001     0.00     0.00  df_gets
  5.66      9.99     0.72  2000002     0.00     0.00  evaluate_at
  4.67     10.58     0.59        1     0.59     1.78  plot_lines
  2.85     10.94     0.36        1     0.36    10.70  get_data
  1.78     11.16     0.23  2000000     0.00     0.00  f_dollars
  1.62     11.37     0.21  2000002     0.00     0.00  execute_at
  1.50     11.56     0.19  2000002     0.00     0.00  push
  1.27     11.72     0.16  2000002     0.00     0.00  pop
  1.27     11.88     0.16  2000000     0.00     0.00  check_missing
  1.11     12.02     0.14  4000000     0.00     0.00  real
  1.03     12.15     0.13  1000001     0.00     0.00  df_readline
  0.87     12.26     0.11  2000057     0.00     0.00  Gcomplex
  0.71     12.35     0.09  2000000     0.00     0.00  gp_strtod
  0.55     12.42     0.07  2000002     0.00     0.00  check_stack
  0.36     12.46     0.05                             df_determine_matrix_info
  0.32     12.50     0.04                             more_on_stack
  0.24     12.53     0.03  2000002     0.00     0.00  reset_stack

As Daniel said, the extra time is due to the overhead of
evaluating each coordinate as an expression rather than as a constant.
( evaluate_at f_dollars push pop check_stack reset_stack )
I don't see any horrible time-wasters in the profile, even when I break
it down to individual lines of code.  However, I still don't know which
bit, exactly, is being accounted for as "system time". Perhaps there
is some system call we can manage to do with out, but at present I
can't think what it would be.

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