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

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

On Wednesday, 23 April, 2014 21:54:56 pl...@pi... wrote:
> On 04/23/14 21:05, Ethan A Merritt wrote:
> >
> > 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
> >
> >
> >
> 
> 
> OK, I was forgetting that a string can be valid as a 'using' specifier 
> for named columns. 

Well yes, but that's not what's happening here.
You are not asking it to read a value from a column named "NaN".
You are asking it to evaluate a value from an in-line expression rather
than from a column, and that in-line expression happens to be the
string constant "NaN".

That's fine if you are going to do something string-like with the value,
but it doesn't work if you actually needed a numerical value.
The bug is that it doesn't fill in a numerical value _at_ _all_.
It just returns the string and leaves the numerical slot full of
whatever was there before - maybe garbage, maybe never initialize,
maybe a previous data value.


> However, here's another oddity:
> 
> gnuplot> plot "-" u ("foo"):2
> input data ('e' ends) > 1 2
> input data ('e' ends) > e
> Warning: empty x range [1.58805e-314:1.58805e-314], adjusting to 
> [1.57217e-314:1.60393e-314]
> Warning: empty y range [2:2], adjusting to [1.98:2.02]
> 
> Why is the string "foo" being evaluated as something close to zero?

Same bug.  The numerical value is meaningless;   you get whatever
contents were there before the data was read from the file.

Basically it's a failure to initialize the return value.
If the program successfully parses a number from the input line
then it's fine.  This is returned.  But if it doesn't successfully
parse a number it returns the uninitialized placeholder.
Very bad, but only triggered by an incorrect plot command.

Fixed now in CVS for both 4.6 and 5.

	Ethan