With a file containg a mix of numbers and NaN values, the smooth functions works as I expect for this command:
plot "foo.dat" using 1:2 smooth unique
But the smooth functions gives a very different result for the equivalent (?) command:
plot "foo.dat" using ($1):($2) smooth unique
For the first command, all points with NaN are silently ignored and one smoothed curve is drawn based on the other points. But for the second command, the curve is separated into multiple parts separated by the NaN values. Each part is smoothed independently of the others, and drawn on top of each other.
There are also similar problems with filter expressions resulting in NaN values, such as:
plot "foo.dat" using 1:($3 > 1 ? $2 : NaN) smooth unique
I've been using GnuPlot 4.6.3 compiled from source on Linux.
Question 1: The smooth algorithm functions in iterpol.c use UNDEFINED points to split a curve into separate parts, via the next_curve function. Is that by design? If so, why?
Question 2: The function datafile.c:df_readascii handles NaN in data files differently depending on if NaN is retrieved via an action table or not. If there is an action table it will return DF_UNDEFINED, but otherwise it will set line_okay = 0 and silently ignore the line. Is that by design? If so, why?
Question 3A: When the filter expression (in the last command above) is evaluated to NaN, the action table function will return NaN, but that is not detected until in axis.h:STORE_WITH_LOG_AND_UPDATE_RANGE, which keeps the point and marks it as UNDEFINED. Is the NaN supposed to be detected by the comparison between temp and VERYLARGE already in eval.c:evaluate_at? If so, that comparison does not work for me (VERYLARGE=DBL_MAX/2-1, GCC=4.6.3, x86), however the similar negated check in axis.h:STORE_WITH_LOG_AND_UPDATE_RANGE works.
Question 3B: Are filter expressions which evaluates to NaN, supposed to result in ignored lines or created points marked as UNDEFINED? Since I'm working with large data sets, which are filtered by expressions such as ($3 > 1 ? $2 : NaN), I would prefere if the filtered data could be ignored instead of being stored as UNDEFINED points and wasting memory and CPU.
Would you accept a patch that would change the behaviour mentioned above?