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

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 31 March 2012, sfeam (Ethan Merritt) wrote:
> On Saturday, 31 March 2012, pl...@pi... wrote:
> >  > 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".
> 
> Please refresh my memory.
> I thought the issue there was that some runtime C libraries accept
> the string NaN as a valid numerical input (gcc for one) but others do
> not (MSVC for example). 

Ah, I found the earlier mail.  It all comes back to me now.
That was the start of my list of "Things to break in Gnuplot version 5".

The list so far:

1) Do not reassign column meanings in the middle of reading data from
   a file.  If whatever worked for the first records fails later, 
   that's an error.

2) Change the behavior of "set range [...] reverse to affect only 
   autoscaling.  This change is already in CVS since it fixes a bug
   and matches the suggested use given in the docs, although it
   doesn't match what the program was actually doing up until now.

3) Rationalize the matrix options for ascii and binary modes.
   Right now the defaults and keywords conflict in the two modes.

4) Distinguish between "splot with lines" and "splot with surface".
   I'm not sure what's the best way to do this, but at a minimum
   it should fix the bug that "unset surface" prevents plotting
   lines and points also.
   E.g.
   splot 'silver.dat' using 1:2:1 with points pt 5 ps 6 lc pal z
   unset surface
   replot   # Where's my plot???

5) The X11 terminal should work in true pixel coordinates rather
   than running from [0:4096] regardless of the window aspect ratio.

6) Change the interpretation of the alpha channel component in
   RGBA colors so that any existing 24-bit RGB triple works also if 
   interpreted as a 32-bit Alpha+RGB with leading component A=0.
   That would allow use of RGBA colors everywhere, but breaks all
   the existing RGB image code and "set style fill solid <alpha>".
   I don't like this much, but I haven't come up with a better way.
   I'm still hoping that inspiration strikes.

The idea is that these all fix long-standing problems or limitations,
but will change the behavior of existing scripts.  Since the project
policy is that we try to guarantee backwards compatibility within a 
major version series, this script breakage would only be acceptable
in connection with release of the next major version - 5.0

==
But none of the above has much to do with Bug #3513138.
We don't the program crashing on binary input, so we've got to
fix that one already for 4.6. 


	Ethan