Re: conflict of separator and missing

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

On Thursday, 16 June, 2016 18:00:00 pl...@pi... wrote:
> On 16/06/16 17:23, sfeam wrote:
> 
> 
> > -   The comparison is to a string, not a numerical value, so -99.00 ne -99.0 ne -99
> Sounds reasonable. From the gnuplot POV it is a missing *string* ; if 
> the cvs is output by a spreadsheet or other software it seems reasonable 
> to expect consistent string formatting ( although Excel could have 
> different cell formats, that is probably too much to try and anticipate.
> 
> 
>  >-   Leading whitespace is ignore but trailing whitespace is not.
> 
> Seems inconsistent. Was this a programming convenience for minimal 
> coding changes or is there a functional logic behind this?

I though the consensus from a couple of days ago was that any difference
in the remainder of the field was significant, hence extra trailing 
characters would mean that the match was imperfect.
Previously "missing A" and "missing B" were both matched as "missing".
Now they are not, even if A is a <tab> or '\n' or '\r'.

>  > ... and requires that the next character is a field-terminator.
> 
> I presume field-terminator.means FS or EOL. 

Separator or null.  
EOL is legal with in a csv field, although if you have such a file good
luck to you. When a line of data is read in to gnuplot it is transferred
to a null-terminated string, so the check for null should catch the true
end-of-line.

> Does this cater for WS at end of line without an explicit FS,
> or does this fall foul of previous point?

You mean like a DOS-style file with <cr><nl> at the end of the line?
So far as I know this is properly handled by stripping away both line
termination characters on input.  But more testing wouldn't hurt.

	Ethan




	Ethan