> >
> > However, this is not how it seems to work. If there are
> > fields in the data file that cannot be transformed to double,
> > df_readline simply skips the line.
>
> That's certainly not true in general, or it wouldn't be able
> to handle files containing text fields.
> Also imageNaN.dem wouldn't provide the output it does.
>
> Simple test: feed it a file junk.dat:
> 1
> 2
> junk
> 3
> 4
>
> gnuplot> plot 'junk.dat' with lp
> ^
> Bad data on line 3
> gnuplot>
Does plot do anything special here?
I have a situation (stolen from the fit function),
which basically says:
while( (i = readline(...)) != EOF ) {
...
And now I feed it your data file and it does NOT
return either DF_MISSING or DF_UNDEFINED!
So it strikes me as if it is not so much "more
complicated", but rather "more simple" cases
where it does the unexpected.
>
>
> But you could be right that there are more complicated cases where
> it unexpectedly fails to return a useful error indicator, or fails
> to return good values from a line that happens to contain a bad one.
>
> > I would have expected it
> > to return DF_MISSING or DF_UNDEFINED. But that's not
> > what I observe.
>
> From my personal TODO file:
> - Sort out handling of junk/NaN/Inf in datafile.c
> + using 1:2:3 and using ($1):($2):($3) should fill in all the legal
> values before returning an error code due to a single bad value
Based on your comment here, I just discovered that
if I enclose the columns in parens [that is using ($1):($2)]
rather than [using 1:2], then df_readline() DOES indeed
return DF_MISSING and DF_UNDEFINED.
Hm. I guess I knew this, although takes out of context like
this, it is surprising.
> + new return code DF_INFINITY for Inf
> + set datafile missing {"keyword"} {NaN} {Inf}
> would explicitly treat NaN or Inf as a missing value, rather than a
> bad one + blank line should be distinguishable from a non-blank line
> containing junk + consistent treatement of NaN (always set point->type ==
> UNDEFINED)
>
|
