gnuplot-beta

Should we provide a keyword than means (1/0) ?

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

I have noticed that many questions posted to the newsgroup
fall into the general category 
"How do I *not* plot part of my data or function?".
The answer usually involves a conditional expression with the
constant value  "1/0"   used to generate invalid data points.

I can see how it would be hard for new users to work this out
on their own.  "Illegal divide by zero" is not usually the 
same as "Omit this point" in the larger world.

So I wonder if it would be a good idea to add some keyword like
"skip" or "omit" or "invalid" or "undefined".  Instead of
writing
	plot <foo> using 1 : ($2 > 0 ? $2 : 1/0)
you could write
	plot <foo> using 1 : ($2 > 0 ? $2 : omit)


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Should we provide a keyword than means (1/0) ?

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

Ethan Merritt wrote:

> So I wonder if it would be a good idea to add some keyword like
> "skip" or "omit" or "invalid" or "undefined".  Instead of
> writing
> 	plot <foo> using 1 : ($2 > 0 ? $2 : 1/0)
> you could write
> 	plot <foo> using 1 : ($2 > 0 ? $2 : omit)

All of those would be fine.  Perhaps NAN as well.

Daniel

Re: Should we provide a keyword than means (1/0) ?

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

On Friday 29 July 2005 04:04 pm, Daniel J Sebald wrote:

> > you could write
> > 	plot <foo> using 1 : ($2 > 0 ? $2 : omit)
> 
> All of those would be fine.  Perhaps NAN as well.

I am surprised to find that NaN is not accepted already.
It's acceptable in a data file.

But extending the expression parser to handle NaN
(and presumably Inf) is a somewhat separate question.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Should we provide a keyword than means (1/0) ?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> I am surprised to find that NaN is not accepted already.
> It's acceptable in a data file.

But not reliably.  It's a feature of the systems sscanf() / strtod() 
implementation whether NaN will be accepted, and if so, which input 
string will get you this result.  Remember: there could still be 
machines out there that don't have NaNs at all.

Re: Should we provide a keyword than means (1/0) ?

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

On Sunday 31 July 2005 12:03 pm, you wrote:
> Ethan Merritt wrote:
> > I am surprised to find that NaN is not accepted already.
> > It's acceptable in a data file.
>
> But not reliably.  It's a feature of the systems sscanf() / strtod()
> implementation whether NaN will be accepted, and if so, which input
> string will get you this result.

Sure. But in this case the behavior of sscanf() or strtod() does not
matter. parse_primary_expression() has:

    } else if (isanumber(c_token)) {
        /* work around HP 9000S/300 HP-UX 9.10 cc limitation ... */
        /* HBB 20010724: use this code for all platforms, then */
        union argument *foo = add_action(PUSHC);
        convert(&(foo->v_arg), c_token);
        c_token++;
    } else if (isletter(c_token)) {
	... check for functions or variables ...
    } else
	... check for operators ...

So even if the code in scanner.c has previously identified this token as
NaN or Inf, parse_primary_expression() will ignore that and instead
try to find a variable with that name.

This seems wrong to me, although no one has complained up til now.
Having gone to the trouble of parsing and categorizing of each token in
scanner.c, we then ignore that work and have parse_primary_expression()
do a less complete check on its own.  Wouldn't it be better to simply
test the flag previously set in token[t_num].l_val.type ?

So instead of the tests above for (isanumber(c_token)) etc, we would
have a switch statement 
	switch(token[t_num].l_val.type)

Yes, I see that the code in scanner.c probably won't catch NaN of Inf
either. But the point is that even if we were to make the code in
scanner() match the code in df_tokenise(), which would make sense for
consistency, it would still be ignored during expression parsing.


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

Re: Should we provide a keyword than means (1/0) ?

[Hans-Bernhard B. <br...@ph...>]

Ethan A Merritt wrote:

> Sure. But in this case the behavior of sscanf() or strtod() does not
> matter. parse_primary_expression() has:

>     } else if (isanumber(c_token)) {
>     } else if (isletter(c_token)) {
>     } else

> So even if the code in scanner.c has previously identified this token as
> NaN or Inf, parse_primary_expression() will ignore that and instead
> try to find a variable with that name.

Not really.  Note how isanumber() is implemented: it returns

	!token[t_num].is_token

i.e. if NaN was found in the command line, this leaves it completely up 
to the scanner whether to interpret that as a token (i.e. keyword or 
variable) or as a number.

Re: Should we provide a keyword than means (1/0) ?

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

> I can see how it would be hard for new users to work this out
> on their own.  "Illegal divide by zero" is not usually the
> same as "Omit this point" in the larger world.
> 	plot <foo> using 1 : ($2 > 0 ? $2 : 1/0)
> 	plot <foo> using 1 : ($2 > 0 ? $2 : omit)

I think it does not matter whether it is 1/0 or omit. I prefer to keep 1/0, 
or type NaN. Rather the current syntax should be better advertised. FAQ, 
documentation?

---
PM