Re: Discussion: What to do if NaN appears in a non-coordinate field?

[<pl...@pi...>]

On 03/31/12 18:39, sfeam (Ethan Merritt) wrote:
> Bug #3513138 reports a problem when NaN appears in a data column
> where gnuplot is expecting to find an extra property.
> The example given is
>       plot 'foo' using 1:2:3 with points lc palette
> The same problem would happen for
>       plot 'foo' using 1:2:3 with points pointsize variable
>
> If NaN appears in the x, y, or z coordinate then the point
> is rejected on input.  But what should we do for these
> cases where the point is in range on x/y/z but a separate
> field is missing or NaN?
>
> 1) Ignore the point (same as a NaN coordinate).
>
> 2) Accept the point but assign the property some default value.
>
> 3) Use the coordinates for auto-scaling but do not draw it.
>
> 4) Something else
>
> The current handling of "with image" data provides some precedent.
> A NaN image pixel is either not drawn at all or is rendered
> in the background color. But the issue of auto-scaling does not
> arise for image plots because omitting a single pixel would not
> change the range.
>
> Should an "invisible" point (i.e. one with NaN for pointsize or
> color) contribute to auto-scaling?
>
> There are probably more obscure cases also, like "with circles"
> where the radius is NaN.  Can you think of any others?
>
>
> 	Ethan
>
> ----------------

Hi Ethan,

I would have thought that any NaN anywhere was basically :"this is not 
valid data ignore it".

A circle with rad="not a number" is "not a circle".

A point of colour index "not a number" is not a point. Why should it be 
part of scaling or anything?

I can see a limited number or reasons for finding a NaN.

1. divide by zero type error, data is bad don't use it. Using a default 
is almost certainly not the correct result otherwise no one would be 
trying to calculate whatever it was to start with.

2. data file has missing data intentionally marked at non existent: it 
should not be used in any way , that's why it was flagged as non existent.

3. programatically creating a NaN to control output: I require a result 
, I explicitly try to exclude it, don't do something (anything) with it .
plot ...... using ($1<1945)?NaN:$1 :2 ...


 > If NaN appears in the x, y, or z coordinate then the point
 > is rejected on input.

I thought when I brought this up a couple of months back the point I 
raised was that this was NOT happening when NaN was in first column. It 
was not being parsed as NaN but "NaN".

I presume whatever action you decide upon, this will now get corrected. 
So if anyone sees a problem with such a change (like this is a feature 
not a bug) please shout now.

Peter.