On Monday, February 06, 2012 09:02:27 am pl...@pi... wrote:
> Hi,
>
> it appears that gnuplot can handle most things it cannot parse in input
> data as unplottable data. All that is _except_ IEEE NaN.
I'm pretty sure that is not true in general.
For instance, the demo "imageNaN.dem" in the standard demo set
illustrates handling NaN in the input data stream.
Here's another simple test case:
gnuplot> set xr [0:5]; set yr [0:5]
gnuplot> plot '-' using 1:2 with lp pt 7
input data ('e' ends) > 1 1
input data ('e' ends) > 2 NaN
input data ('e' ends) > 3 3
input data ('e' ends) > 4 4
input data ('e' ends) > e
Now it is true that some support libraries do not recognize "NaN"
as legal input (including, I believe, MSVC). But that's a different
failure mode.
What exactly was your plot command?
Ethan
>
> Of course any specific value can be defined by 'set datafile missing'
> but there is no default for this.
>
> This situation has the paradoxical effect mentioned above that if I have
> a data line that reads " ugh 0.0 " , it will be skipped as unreadable
> but if I have " NaN 0.0 " it will cause the plot to fail with
> "unreadable" data.
>
> It seems it is precisely because gnuplot IS able to parse NaN that it is
> causing an error. If it could not understand it , it would ignore the line.
>
> Since gnuplot would effectively regard this as a NaN if it could not
> parse it , it seems a bit illogical that having parsed "NaN" as meaning
> NaN it refuses to act on it being NaN and triggers an error.
>
> Is there some problem with this value, when it is parsed in input, being
> used for what it is unless another "missing" value has been explicitly
> defined with 'set datafile missing' ?
>
>
> Thanks.
--
Ethan A Merritt
Biomolecular Structure Center, K-428 Health Sciences Bldg
University of Washington, Seattle 98195-7742
|
