Re: gnuplot changes affects octave

[David Bateman]

John W. Eaton wrote:
> On  6-Aug-2006, Dmitri A. Sergatskov wrote:
> 
> | Recently gnuplot (version 4.1) changed the way it handles NaN and
> | their meaning. That affects gplot.m and probably some other octave
> | scripts.
> | 
> | E.g. consider the following data file (say "test1.dat")
> | 
> | # -- begin --
> | 0 1
> | 1 0
> | NaN NaN     
> | 1 2
> | 2 1
> | # -- end
> | 
> | In gnuplot 4.0
> | plot "test1.dat" with line
> | will produce two line segments; NaN are handled automatically.
> | 
> | In gnuplot 4.1 one needs to do first
> | set datafile missing "NaN"
> | (note that will *not* handle "nan" only "NaN)
> | but than it will connect the segments between (1 0) and (1 2).
> | 
> | If one replaces line that has NaNs with an empty line, the connecting
> | segment will not be there.
> 
> So are you saying that Octave should be scanning the data looking for
> rows of NaNs and then converting those to empty lines in the data file
> that it creates for gnuplot to plot?  This should work with both old
> and new versions of gnuplot, correct?  If so, then how about the
> following changes?  It seems a bit messy to just be using int values
> for the strip_nan_and_inf parameter, but it works.
> 
> jwe
> 

That's a real abuse of the save_ascii function. The only reason this is
ok, is that should only be the plot code that uses the strip_nan_and_inf
flag (can this be guarenteed or at least confirmed)? I'd also be happier
is the CMatrix::save_ascii and Matrix::save_ascii function had another
name to avoid confusion with the function of the same name in the
octave_value classes.

D.