Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2006-08-11 20:46:15
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-11 21:59:19
|
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
|
|
From: Petr M. <mi...@ph...> - 2006-08-11 22:15:02
|
>> 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
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-11 22:28:08
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-11 22:33:21
|
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(). |
|
From: <br...@ph...> - 2006-08-13 05:11:32
|
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.
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-13 06:44:31
|
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
|
|
From: Petr M. <mi...@ph...> - 2006-08-13 17:41:30
|
>> 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 |
|
From: Petr M. <mi...@ph...> - 2006-08-13 20:47:19
|
>> 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
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-13 20:59:57
|
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
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-08-13 22:16:27
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-13 23:18:40
Attachments:
existerror-djs-13aug2006.patch
|
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
|
|
From: Petr M. <mi...@ph...> - 2006-08-14 04:38:12
|
>>> 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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-08-14 05:04:38
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-14 05:28:59
|
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
|
|
From: Petr M. <mi...@ph...> - 2006-08-14 05:21:31
|
>> 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
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-08-14 05:49:10
|
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
|
|
From: Petr M. <mi...@ph...> - 2006-08-14 06:05:34
|
> 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
|
|
From: Daniel J S. <dan...@ie...> - 2006-08-14 06:20:17
|
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
|
