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

Re: Interesting bug: relative offset + log scale = problem

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

On Wednesday 16 August 2006 12:26 pm, you wrote:

> Well, the test should be against 
> the eventual placement, not the offset, right? 
> I would guess this:
>
> 	    x = map_x((hist->start + hist->end) / 2.);
> 	    y = xlabel_y;
> 	    x += (int)xoffset_d;
> 	    y += (int)yoffset_d + 0.25 * term->v_char;
>
> has to come before this:
>
> 	    map_position_r(&(histogram_opts.title.offset), &xoffset_d,
> &yoffset_d, "histogram");

That would be absurd.
The whole *point* of map_position_r() is to calculate for you
what needs to be added to the x,y coordinates.  If you're going
to do that everywhere in-line, then there is no need for
the map_position_r() routine at all.

I am leaning towards the idea that map_position_r() needs a
top level check on entry for zero offsets.
Who cares whether it's zero characters, zero plot units,
or zero something else?
Zero is zero.

But it may also be true that map_position_r() should never
do range checking, even for non-zero offsets.  The combination
of   base_position=BIGNUM  and offset=(-BIGNUM)  may be
nicely in range even if neither would be allowed individually
as a coordinate value.



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

Re: Interesting bug: relative offset + log scale = problem

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

Ethan Merritt wrote:
> On Wednesday 16 August 2006 11:13 am, Daniel J Sebald wrote:
> 
>>Ethan Merritt wrote:
>>
>>>Someone on the usenet group reported a problem that boils down to
>>>  set log y
>>>  plot newhistogram "title",   <foo>, <baz>, ...
>>>
>>>The result is an error return
>>>  histogram has y coord of 0; must be above 0 for log scale!
>>>
>>>Now in fact the histogram itself is fine.
>>
>>How is this fine?  If one of the histogram bins has a value of 0,
>>log(0) is undefined.  Do you mean there is special code to deal with
>>this case?
> 
> 
> The error message comes from the title.
> Remove the title, no error message - the histogram itself has
> no problem.
> 
> The error message is totally a false alarm, based on checking
> the "offset" value of the title string.

Oh, yes now I see what you mean.  Well, the test should be against the eventual placement, not the offset, right?  Writing a patch for this would take a bit, but I don't see how one can do arithmetic on offsets using a logarithm scale, i.e., log(x+y) != log(x) + log(y).  I would guess this:

	    x = map_x((hist->start + hist->end) / 2.);
	    y = xlabel_y;
	    x += (int)xoffset_d;
	    y += (int)yoffset_d + 0.25 * term->v_char;

has to come before this:

	    map_position_r(&(histogram_opts.title.offset), &xoffset_d, &yoffset_d,
			   "histogram");

in some fashion.

Dan

Re: Interesting bug: relative offset + log scale = problem

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

On Wednesday 16 August 2006 11:13 am, Daniel J Sebald wrote:
> Ethan Merritt wrote:
> > Someone on the usenet group reported a problem that boils down to
> >   set log y
> >   plot newhistogram "title",   <foo>, <baz>, ...
> >
> > The result is an error return
> >   histogram has y coord of 0; must be above 0 for log scale!
> >
> > Now in fact the histogram itself is fine.
>
> How is this fine?  If one of the histogram bins has a value of 0,
> log(0) is undefined.  Do you mean there is special code to deal with
> this case?

The error message comes from the title.
Remove the title, no error message - the histogram itself has
no problem.

The error message is totally a false alarm, based on checking
the "offset" value of the title string.


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

Re: Interesting bug: relative offset + log scale = problem

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

Ethan Merritt wrote:
> Someone on the usenet group reported a problem that boils down to
>   set log y
>   plot newhistogram "title",   <foo>, <baz>, ...
> 
> The result is an error return
>   histogram has y coord of 0; must be above 0 for log scale!
> 
> Now in fact the histogram itself is fine.

How is this fine?  If one of the histogram bins has a value of 0, log(0) is undefined.  Do you mean there is special code to deal with this case?

This error message
> is triggered by attempting to place "title",

By title you mean a title for each individual bin?  The title for the plot should always be layed out according to a linear scale of screen coordinates I would think. 

Dan

Interesting bug: relative offset + log scale = problem

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

Someone on the usenet group reported a problem that boils down to
  set log y
  plot newhistogram "title",   <foo>, <baz>, ...

The result is an error return
  histogram has y coord of 0; must be above 0 for log scale!

Now in fact the histogram itself is fine. This error message
is triggered by attempting to place "title", which has an 
implicit offset of (0,0) relative to whatever auto-generated
position the plot layout code settles on. 

  graphics.c 4891:    map_position_r(&(histogram_opts.title.offset),
                                     &xoffset_d, &yoffset_d,
                                     "histogram");

and then in map_position_r we trip over:

  switch (pos->scaley) {
  case first_axes:
    {
      double yy = axis_log_value_checked(FIRST_Y_AXIS, pos->y, what);
                  ^^^^^^^^^^^^^^^^^^^^^^
      *y = yy * axis_array[FIRST_Y_AXIS].term_scale;
      return;
    }

I can fix this particular mess-up by initializing the offset 
explicitly to be a character offset rather than a y1axis plot offset.
That's fine. 
 
But the larger question is, why should the code invoke a range
check on the value of a relative position in the first place?

An increment of zero should be legal, log scale or not.
Isn't the check against axis_log_value_checked() in map_position_r()
a mistake?


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

Re: gnuplot on FreeBSD

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

Dhiman Barman wrote:
> The following is a summary of what one has to do to hack gnuplot4.1's prepare
> to work on FreeBSD; thanks to Dan Andersen who made it work:

Thanks Dhiman.  I know little about the prepare innards, so I will simply ask questions, for the list not just Dhiman.

> in the script 'prepare':
> 
> change all instances of 'make' with gmake.  Freebsd has it's
> own BSDesque make program.  The makefiles in gnuplot use features
> unavailable in bsd make, so gnu make must be used.

Is gmake something available on all platforms?  Or can the prepare script figure out somehow when to use make vs. gmake?

> 
> work around FreeBSD's choice of naming autoconf and
> automake binaries with version numbers.  You can either modify the
> prepare script directly, or create a ~/bin directory and create symlinks
> like ~/bin/aclocal -> /usr/local/bin/aclocal19

Again, isn't this something that prepare can figure out?

Dan

gnuplot on FreeBSD

[Dhiman B. <dh...@ca...>]

The following is a summary of what one has to do to hack gnuplot4.1's prepare
to work on FreeBSD; thanks to Dan Andersen who made it work:

in the script 'prepare':

change all instances of 'make' with gmake.  Freebsd has it's
own BSDesque make program.  The makefiles in gnuplot use features
unavailable in bsd make, so gnu make must be used.

work around FreeBSD's choice of naming autoconf and
automake binaries with version numbers.  You can either modify the
prepare script directly, or create a ~/bin directory and create symlinks
like ~/bin/aclocal -> /usr/local/bin/aclocal19

Dhiman

Re: installation

[Dhiman B. <dh...@ca...>]

Hi, 
  Its not enough to do ./prepare (it hanged at places) as FreeBSD (that I am 
using) has its own way of making config file and Makefile. 
FreeBSD has its own versioning problems and it installs binaries 
as 'aclocal19' etc. 

  I am trying to make it work on FreeBSD, lets see. 

Thanks,
Dhiman 
  

On Mon, Aug 14, 2006 at 10:33:01PM -0500, Daniel J Sebald wrote:
> Dhiman Barman wrote:
> >Hi,
> >  I tried to install gnuplot 4.1 beta version from it .tar.gz source
> >package.
> >I could not install , infact could not find ./configure command.
> >  Any help ?
> 
> Be more specific about the version, please.  (I can't imagine "configure" 
> isn't in some tar file supplied by the developers.  You typed something 
> like "tar -xzf <gnuplot>.tar.gz"?)  Email me directly; building gnuplot 
> really isn't discussion list material.
> 
> You may also want to look into getting the CVS version:
> 
> http://sourceforge.net/cvs/?group_id=2055
> 
> Dan

Re: installation

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

Daniel J Sebald wrote:

>> http://www.gnuplot.info/development/binaries/gnuplot-4.1.0-2006-24-04.tar.gz

> That snapshot will likely be out of date soon.

What do you mean, "soon"?  It already *is* out of date.  By almost 4 months.

Re: installation

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

Dhiman Barman wrote:
> H,
>   I tried the following tar.gz file for version 4.1
> http://www.gnuplot.info/development/binaries/gnuplot-4.1.0-2006-24-04.tar.gz
> 
> 
> 
> thanks,
> dhiman

Sure enough.  There is no ./configure in that tar file.  You must run prepare first, i.e.,

./prepare; ./configure; make install

That snapshot will likely be out of date soon.

Dan

Re: installation

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

Dhiman Barman wrote:
> Hi,
>   I tried to install gnuplot 4.1 beta version from it .tar.gz source
> package.
> I could not install , infact could not find ./configure command.
>   Any help ?

Be more specific about the version, please.  (I can't imagine "configure" isn't in some tar file supplied by the developers.  You typed something like "tar -xzf <gnuplot>.tar.gz"?)  Email me directly; building gnuplot really isn't discussion list material.

You may also want to look into getting the CVS version:

http://sourceforge.net/cvs/?group_id=2055

Dan

installation

[Dhiman B. <dh...@ca...>]

Hi,
  I tried to install gnuplot 4.1 beta version from it .tar.gz source
package.
I could not install , infact could not find ./configure command.
  Any help ?

Thanks,
Dhiman

Re: exist, configure, doc2tex and \index

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

Petr Mikulik wrote:
>> You are missing my point.
>> foo is a variable.  It may hold a string ("xxx") or it may hold an 
>> integer (9).
>> It is legal to call
>>     if (exists(foo))
>> in the first case, and the return code is 1, which tells you that foo 
>> contains
>> the name of a defined variable.
>>
>> As I see it, if foo = 9 then  exists(foo) should return 0, which tells 
>> you that
>> foo does _not_ contain the name of a defined variable.  That is what 
>> it does
>> now, and I think it is correct.  Daniel's patch would have it error 
>> out rather
>> than returning.
> 
> 
> Ok, you are right.
> 
>>> gnuplot> help exists
>>>   `exists("X")` returns 1 if a variable named X has been defined,
>>>   otherwise it returns 0.
>>
>>    ^^^^^^^^^^^^^^^^^^^^^^^
>>
>> That is exactly what I am saying.  If the argument to exists() is not a
>> defined variable name  (i.e. a string), then exists() should return 0.
>> Not error out;  return 0.
> 
> 
> Could you perhaps add this into "help exists"?

More than that.  Rephrase things to remove ambiguity.  One can look at the above help and assume implicitly that X must be inside a string.  How about:

`exists(ARG)` returns 1 if its argument is a string containing
a variable that has been defined, e.g., ARG="X" where X has
been defined.  Otherwise the function returns 0.

THEN we must change this behavior

gnuplot> print exists()
                      ^
         invalid expression
gnuplot> print exists(empty)
         undefined variable: empty

so that both return 0.  That or change the help description to refine things even further:

`exists(ARG)` returns 1 if its argument is a string containing
a variable that has been defined, e.g., ARG="X" where X has
been defined.  Otherwise the function returns 0 if ARG is a
valid expression and errors if ARG is not a valid expression.

Daniel

Re: exist, configure, doc2tex and \index

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

> You are missing my point.
> foo is a variable.  It may hold a string ("xxx") or it may hold an integer (9).
> It is legal to call
> 	if (exists(foo))
> in the first case, and the return code is 1, which tells you that foo contains
> the name of a defined variable.
>
> As I see it, if foo = 9 then  exists(foo) should return 0, which tells you that
> foo does _not_ contain the name of a defined variable.  That is what it does
> now, and I think it is correct.  Daniel's patch would have it error out rather
> than returning.

Ok, you are right.

>> gnuplot> help exists
>>   `exists("X")` returns 1 if a variable named X has been defined,
>>   otherwise it returns 0.
>    ^^^^^^^^^^^^^^^^^^^^^^^
>
> That is exactly what I am saying.  If the argument to exists() is not a
> defined variable name  (i.e. a string), then exists() should return 0.
> Not error out;  return 0.

Could you perhaps add this into "help exists"?

---
PM

Re: \n in GPVAL_COMPILE_OPTIONS

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

Ethan A Merritt wrote:

>>Is this string supposed to be used as part of a string argument somewhere?
> 
> 
> It is the string printed by "show version long".

Oh, so that when printed it isn't one big long string:

gnuplot> print GPVAL_COMPILE_OPTIONS
+READLINE  -LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA
+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION
-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE
+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE

Got it.

Dan

Re: \n in GPVAL_COMPILE_OPTIONS

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

On Sunday 13 August 2006 10:54 pm, Daniel J Sebald wrote:
> What do the "\n" of the GPVAL_COMPILE_OPTIONS mean?
> 
>         GPVAL_COMPILE_OPTIONS = "+READLINE  -LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  \n+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  \n-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  \n+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  \n"
> 
> Is this string supposed to be used as part of a string argument somewhere?

It is the string printed by "show version long".


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

Re: exist, configure, doc2tex and \index

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

On Sunday 13 August 2006 10:21 pm, you wrote:
> >> This is the correct patch! With this patch, the exists(...) works as
> >> expected.
> >
> > I disagree.
> >
> > Before
> > -------
> > gnuplot> foo = 8
> > gnuplot> if (!exists(foo)) print "Hi"
> 
> This is wrong! You must write exists("foo"). The argument of exists() must 
> always be a string:

You are missing my point.
foo is a variable.  It may hold a string ("xxx") or it may hold an integer (9).
It is legal to call
	if (exists(foo))
in the first case, and the return code is 1, which tells you that foo contains
the name of a defined variable.

As I see it, if foo = 9 then  exists(foo) should return 0, which tells you that
foo does _not_ contain the name of a defined variable.  That is what it does
now, and I think it is correct.  Daniel's patch would have it error out rather
than returning.
 
> gnuplot> help exists
>   `exists("X")` returns 1 if a variable named X has been defined, 
>   otherwise it returns 0.
    ^^^^^^^^^^^^^^^^^^^^^^^

That is exactly what I am saying.  If the argument to exists() is not a 
defined variable name  (i.e. a string), then exists() should return 0.
Not error out;  return 0.


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

\n in GPVAL_COMPILE_OPTIONS

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

What do the "\n" of the GPVAL_COMPILE_OPTIONS mean?

        GPVAL_COMPILE_OPTIONS = "+READLINE  -LIBREADLINE  +HISTORY  +BACKWARDS_COMPATIBILITY  +BINARY_DATA  \n+GD_PNG  +GD_JPEG  +GD_TTF  +GD_GIF  +ANIMATION  \n-NOCWDRC  +X11  +X11_POLYGON  +MULTIBYTE  +USE_MOUSE  +HIDDEN3D_QUADTREE  \n+DATASTRINGS  +HISTOGRAMS  +OBJECTS  +STRINGVARS  +MACROS  +IMAGE  \n"

Is this string supposed to be used as part of a string argument somewhere?

Re: exist, configure, doc2tex and \index

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

Ethan A Merritt wrote:
> On Sunday 13 August 2006 09:37 pm, you wrote:
> 
>>>>>Shouldn't we expect the same error message?
>>>>>(and "internal error: ...", not "... error : ...")
>>>
>>>Is this 4.2 critical?
>>
>>Yes; you've shown that exists() doesn't work properly.
>>
>>
>>>The important thing is the return value, not the error message.
>>
>>This is the correct patch! With this patch, the exists(...) works as 
>>expected.
> 
> 
> I disagree.
> 
> Before
> -------
> gnuplot> foo = 8
> gnuplot> if (!exists(foo)) print "Hi"
> Hi
> 
> After
> -----
> gnuplot> foo = "baz"
> gnuplot> if (!exists(foo)) print "Hi"
> Hi
> gnuplot> foo = 8
> gnuplot> if (!exists(foo)) print "Hi"
>          internal error : non-string argument
> 
> 
> Are you arguing that the old behaviour was wrong, and the
> new behaviour is correct?   
> 
> I think the original behaviour was correct:
> if foo does not point to the name of a variable, exists(foo)
> returns 0.  After Daniel's patch it doesn't return at all;
> it errors out.  That means you cannot use exists(foo) to
> test whether it contains the name of a variable.

Again, I see what you are saying.  However, before the patch, let's say that foo is not defined.  Then this:

gnuplot> print exists(foo)
         undefined variable: foo

should also return a 0 by the same logic that

gnuplot> foo = 8
gnuplot> print exists(foo)
0

returns a zero.  That is, foo doesn't contain the name of a variable; it doesn't contain anything because it doesn't exist.  I ask if, in fact, "exists" does intend to answer that question, i.e., Contains a variable?  Perhaps there should be another function for that, isint(), isvar().  ??

Also in the old behavior, how is one to interpret the following?

gnuplot> print exists(23)
0

That 23 doesn't contain a variable?  In one sense, 23 does exist.  It's an integer value, e.g., one types "plot 23" and gets a valid plot.

So, I'm on the fence on this one.  I don't see a convincing argument for one way over the other just yet.

Dan

Re: exist, configure, doc2tex and \index

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

>> This is the correct patch! With this patch, the exists(...) works as
>> expected.
>
> I disagree.
>
> Before
> -------
> gnuplot> foo = 8
> gnuplot> if (!exists(foo)) print "Hi"

This is wrong! You must write exists("foo"). The argument of exists() must 
always be a string:

gnuplot> help exists
  `exists("X")` returns 1 if a variable named X has been defined, otherwise
  it returns 0.


It was defined() who used to accept non-string variable.

---
PM

Re: exist, configure, doc2tex and \index

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

On Sunday 13 August 2006 09:37 pm, you wrote:
> >>> Shouldn't we expect the same error message?
> >>> (and "internal error: ...", not "... error : ...")
> >
> >Is this 4.2 critical?
> 
> Yes; you've shown that exists() doesn't work properly.
> 
> > The important thing is the return value, not the error message.
> 
> This is the correct patch! With this patch, the exists(...) works as 
> expected.

I disagree.

Before
-------
gnuplot> foo = 8
gnuplot> if (!exists(foo)) print "Hi"
Hi

After
-----
gnuplot> foo = "baz"
gnuplot> if (!exists(foo)) print "Hi"
Hi
gnuplot> foo = 8
gnuplot> if (!exists(foo)) print "Hi"
         internal error : non-string argument


Are you arguing that the old behaviour was wrong, and the
new behaviour is correct?   

I think the original behaviour was correct:
if foo does not point to the name of a variable, exists(foo)
returns 0.  After Daniel's patch it doesn't return at all;
it errors out.  That means you cannot use exists(foo) to
test whether it contains the name of a variable.


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

Re: exist, configure, doc2tex and \index

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

>>> Shouldn't we expect the same error message?
>>> (and "internal error: ...", not "... error : ...")
>
>Is this 4.2 critical?

Yes; you've shown that exists() doesn't work properly.

> The important thing is the return value, not the error message.

This is the correct patch! With this patch, the exists(...) works as 
expected.


Note: non-INTGR, INT or CMPLX, ... cannot it write INTEGER, COMPLEX?

---
PM

Re: exist, configure, doc2tex and \index

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

Ethan A Merritt wrote:
> On Sunday 13 August 2006 01:47 pm, Petr Mikulik wrote:
> 
>>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 : ...")
> 
> 
> Maybe.  I'm not sure.
> The important thing is the return value, not the error message.
> 
> Consider the patch
> ###################################################################
> --- gnuplot/src/standard.c      2006-07-15 19:14:01.000000000 -0700
> +++ gnuplot-cvs/src/standard.c  2006-08-13 14:52:24.000000000 -0700
> @@ -989,6 +989,7 @@
>         gpfree_string(&a);
>         push(Ginteger(&a, udv->udv_undef ? 0 : 1));
>      } else {
> +       int_warn(NO_CARET,"internal error : non-string argument");
>         push(Ginteger(&a, 0));
>      }
>  #endif
> ###################################################################
> With this patch in place, you now see
> 
> gnuplot> print exists(foo)
>          undefined variable: foo
> gnuplot> print exists(89)
>          warning: internal error : non-string argument
> 0
> gnuplot> foo = 89
> gnuplot> print exists(foo)
>          warning: internal error : non-string argument
> 0
> 
> So with the patch it does print "non-string argument" as
> a warning.  But should it return 0, or 1?  At this point we
> do know that there was a variable "foo", even if the query
> contained a syntax error. It is complicated by the question
> of recursion:
> 
> gnuplot> foo = "var"
> gnuplot> print exists(foo)
> 0
> gnuplot> var = 89
> gnuplot> print exists(foo)
> 1
> 
> In this example foo is a defined variable, but is the lack
> of quotes an unintentional syntax error, or is it an intended
> indirect query?  There is no way of knowing.
> 
> Daniel Sebald wrote
> 
>>Is this 4.2 critical, Ethan? 
>>Otherwise, we can create a bug report and come back to it. 
> 
> 
> But I don't actually think it's a bug.
> At worst you could call it a lack of an error message.
> 
> But as the example above shows (and you gave a similar one)
> it is not always an error to pass an unquoted variable name.
> So although the error message is strictly speaking correct,
> it may still be confusing.

OK, I see your point.  However, why is it necessary to have exists(#) return a value?  Could the int_warn() be changed to int_error()?

(Attached is a patch, overblown containing an attempt to place all "internal error" messages under a set of defines.  Toss it if you don't want that much.)  The output is:

Terminal type set to 'x11'
gnuplot> print exists(foo)
         undefined variable: foo

gnuplot> print exists(89)
         internal error: STRING operator applied to non-STRING type

gnuplot> foo = 89
gnuplot> print exists(foo)
         internal error: STRING operator applied to non-STRING type

gnuplot> foo = "var"
gnuplot> print exists(foo)
0
gnuplot> var = 89
gnuplot> print exists(foo)
1

Re: exist, configure, doc2tex and \index

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

On Sunday 13 August 2006 01:47 pm, Petr Mikulik wrote:
> 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 : ...")

Maybe.  I'm not sure.
The important thing is the return value, not the error message.

Consider the patch
###################################################################
--- gnuplot/src/standard.c      2006-07-15 19:14:01.000000000 -0700
+++ gnuplot-cvs/src/standard.c  2006-08-13 14:52:24.000000000 -0700
@@ -989,6 +989,7 @@
        gpfree_string(&a);
        push(Ginteger(&a, udv->udv_undef ? 0 : 1));
     } else {
+       int_warn(NO_CARET,"internal error : non-string argument");
        push(Ginteger(&a, 0));
     }
 #endif
###################################################################
With this patch in place, you now see

gnuplot> print exists(foo)
         undefined variable: foo
gnuplot> print exists(89)
         warning: internal error : non-string argument
0
gnuplot> foo = 89
gnuplot> print exists(foo)
         warning: internal error : non-string argument
0

So with the patch it does print "non-string argument" as
a warning.  But should it return 0, or 1?  At this point we
do know that there was a variable "foo", even if the query
contained a syntax error. It is complicated by the question
of recursion:

gnuplot> foo = "var"
gnuplot> print exists(foo)
0
gnuplot> var = 89
gnuplot> print exists(foo)
1

In this example foo is a defined variable, but is the lack
of quotes an unintentional syntax error, or is it an intended
indirect query?  There is no way of knowing.

Daniel Sebald wrote
> Is this 4.2 critical, Ethan? 
> Otherwise, we can create a bug report and come back to it. 

But I don't actually think it's a bug.
At worst you could call it a lack of an error message.

But as the example above shows (and you gave a similar one)
it is not always an error to pass an unquoted variable name.
So although the error message is strictly speaking correct,
it may still be confusing.

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

Re: exist, configure, doc2tex and \index

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

Petr Mikulik wrote:
>>>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 : ...")

Yes, on both accounts.  Otherwise one gets the following results:

gnuplot> print exists(alpha)
         undefined variable: alpha

gnuplot> print exists("alpha")
0
gnuplot> alpha = 5
gnuplot> print exists(alpha)
0
gnuplot> print exists("alpha")
1

The third example of "exists" above is slightly misleading.  Forcing the string error message will avoid any such confusion.

Is this 4.2 critical, Ethan?  Otherwise, we can create a bug report and come back to it.

Dan