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

[Juhász P. <pet...@gm...>]

On Sat, 2012-03-31 at 09:39 -0700, 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
> 

I'd say the cleanest and most consistent solution would be ignoring the
point completely. At least for circles, radius is an essential property,
a circle with a NaN radius is not a circle at all (NaC). Same for
ellipses.

A counterargument could be made for point colors, sizes (and perhaps
some other attributes), because those are optional properties. Still, if
the using specification says "1:2:3 with points lc palette" and
column(3) is NaN for a certain point, then the specification is
incomplete for that point, and thus it is best if it doesn't influence
the plot in any way.

Péter Juhász