Re: what is the use of "u" in tabulated output?

[Ethan A M. <sf...@us...>]

On Wednesday, 23 April, 2014 20:50:18 pl...@pi... wrote:
> On 04/23/14 20:30, Ethan A Merritt wrote:
> >
> > On Sunday, 20 April, 2014 11:02:48 pl...@pi... wrote:
> >> On 04/20/14 10:48, pl...@pi... wrote:
> >>>
> >>> I often use conditional using clauses to plot part of a range of data
> >>>
> >>> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
> >
> > [defer discussion of tabular output to a separate reply]
> >
> >> I've just found out the if I used "NaN" as a string instead of NaN in
> >> the using clause I get the result I expected: the data cuts off at the
> >> required date.
> >>
> >> plot datafile using   (($1<=1995.55)?$1:"NaN"):(2*fcos1($1))
> >
> > I think that's because you gave a string where a number was expected.
> > The fact that the string contained "NaN" rather than, say, "foo" is not
> > relevant.
> >
> >> It seems there is an inconsistency in the way this is being handled.
> >
> > I agree. This is a bug.  If the program finds a string where a number
> > was expected, the numerical value returned to get_data() should be
> > NaN rather than some random or left-over value from an earlier line.
> > This should get a fix for both 4.6 and 5.
> >
> > 	Ethan
> >
> 
> I would have expected the parser the throw this out since it is 
> illegitimate input in this context.
> 
> I only tried this to see what would happen when the correct syntax 
> produced garbage output.
> 
> Why didn't the parser reject it ?

It's fine at the level of parsing.  There's nothing intrinsically wrong
with reading in a data string rather than a number.  The problem
only comes later if you try to use that for something that really does
require a numerical value.   The bug is that there is still an old
numerical value hanging around from an earlier read operation that
is used instead.  That shouldn't happen.

	Ethan