Re: change in handling missing data.

[Dmitri A. S. <das...@gm...>]

On 8/6/06, Ethan A Merritt <merritt@u.washington.edu> wrote:
> On Sunday 06 August 2006 02:20 pm, Dmitri A. Sergatskov wrote:
> > I there any way I can get an old (4.0) behavior with new
> > gnuplot when plotting data files with missing data?
>
> Short answer:  Yes.
>         plot 'test1.dat' using ($1):($2) with lines

I figure this out. This has a couple problems.
The issue came about from using gnuplot from octave. Since
octave interpreter writes the (temporary) data file for gnuplot to
plot, it knows the data format and thus does not need to specify
"using" string.
A simple benchmark (time gnuplot < cmd) shows that (on my computer
at least) plot "file" using ($1):($2) takes about 150% as long
as plot "file".
So I was hoping there is some setting that would allow old
behavior. Apparently it is not the case, so be it, we will adapt.
Perhaps it is time to convert to "binary" datafile format...

>
> Longer answer:
>
> The whole "missing" issue drives me to distraction.
> No two people expect the same thing from it, so it's no wonder
> that many bug reports are filed against it.  3.7 and 4.0 did
> not behave identically, so existing scripts are not an
> infallible guide either.
>
> For what it's worth...
> Your "NaN" strings *are* being read as legal IEEE format numbers.
> Using "set datafile missing ..." is not the issue.
> The issue is what to do when a number is not legal (NaN, Inf,
> underflow).

It is an issue, because previously I did not bother to check
if NaNs in my files written as "NaN" or as "nan".
Also, how do I handle file that has both "NaN" and "Inf"?

> Plot, or not plot?
> Increment the line number, or not?
> Error message?

I understand this problem. I also prefere the old (4.0) behavior.
For one thing, since the plot is the graphical representation of
the data I want to have a visual feedback that I have "funny"
datapoints. Broken line provides such a feedback. Plotting
over it -- hides it.
Again, I am not asking to change anything. At least not at this
moment...

>
>         EAM
>

Sincerely,

Dmitri.
--