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