Re: what is the use of "u" in tabulated output?

[Ethan M. <eam...@gm...>]

> Is it a safe bet that no one has a script that relies on meaningless junk?

Not the junk values themselves.  But there may be scripts that depend on a
1-to-1 agreement between number of lines in and number of lines out.   This
is the case, for instance, when dumping a matrix or image array.  If you
skip a line just because it contains an undefined or NaN entry then the
whole array grid alignment fails.

> This was presumably an oversight when NaN was added. Is anyone really
using this "feature"?

The 'u' flag was already in the code when it was imported into CVS back in
1999. So no, it doesn't have anything to do with NaN.

That said, I really don't know whether anyone uses it.

> What is the most consistent with a terminal plot ?

That may be the wrong way to look at it.   To the extent that "set table"
is used to produce intermediate data for reading back in later, it is more
important to ask for consistency with the input format.  That's why the
"set table" output writes 1 or 2 blank lines between curves and data
blocks, and why it writes out both INRANGE and OUTRANGE values.  The idea
is not to duplicate that plot that would have produced using the current
axis range, but to save the data so that it can be plotted later perhaps
with different ranges.

===

Let me back up one step and explain why I think it made sense to add the
"plot ... with table" option for version 5.  Previously when you said "set
table", or before that when you said "set terminal table", a [s]plot
command would cause the program to (1) read in whatever data it needed for
the plot, filtering through axis range limits, style-specific
transformations,  etc as it went and then (2) instead of actually plotting
the data it would write to the table file instead.   This 2-step process is
significant because if the program sees a NaN (old style 1/0) in step 1 it
does not store any data values internally - just a flag that the point was
undefined.  So in step 2 there are no values available to write out.  I'm
not sure but I think originally it would have written all zeros rather than
the current bug's random garbage, but either way the only correct item on
the output line is the 'u'.

The new "with table" mode is different.  It kicks in earlier and does the
whole table generation process in a single step.  So there is a chance to
keep more of the original data since it isn't filtered by the current axis
ranges, plot style-specific filtering, and so on.  While the reason it was
proposed in the first place was simply that it can handle more columns than
any "real" plot style, I think these other differences are equally
important.