Re: 'with pixels' (was Re: Engines are started; ...)

[Hans-Bernhard B. <br...@ph...>]

On Sat, 10 Jul 2004, Ethan A Merritt wrote:

> Hans-Bernhard Broeker <br...@ph...> wrote:
> > Ethan A Merritt wrote:
> > > The code in datafile.c and elsewhere (df_readline is not so much
> > > the culprit here) makes an assumption that it can deduce the style of
> > > plot based on the number of input columns requested.
> >
> > Could you show a concrete example of that?
> 
> The worst offenders are one level up, in plot[23]d.c in the routines
> get_data and get_3ddata.  Each of these contains a huge switch
> statement that controls the interpretation of input data columns
> based on the total number of returned columns.  Within each
> 'case <ncols>:' of the switch statement, the code then tries to
> run through all possible plot modes that could have generated
> that number of input columns. I think this is an example of the tail
> wagging the dog;  the main switch statement should rather be
> over the plot types.

I agree wholeheartedly that that code needs to be revamped in a major way.  
But that has no relevance at all to the job to be done by datafile.c. As
long as the 'using' syntax is based on an unstructured list of expressions
rather than named columns like this

	plot 'data' using (x 1, y 2, yhigh 3, ylow 4) 

, the mess in get_{3d,}data() is going to stay as it is.  It's not pretty,
admitted, but it has nothing to do with the point at hand.  Actually,
the fact that this stuff is *not* done in datafile.c is what I'm talking
about.  It's not in there, and it shouldn't be.

So, let's see: the general plan (before datastrings) is

*) datafiles have colums
*) 'using' processes columns into records of at most 7 numbers
*) get_data() maps numbers from that record to data points

Of these three actions, only the first two take place in datafile.c At
some point in the process, datafile handling *will* become dependent on
the plot style, but datafile.c is not where that point should be.

I think we may have to turn all that on its head: let the caller tell the
df_... routines in advance how many using specs it needs, and what values
(axis assignment, time/date flag, datastring flag) each of those should
represent.

> The problematic code in df_readline() itself is the bit which decides
> where to stuff the input values based on the number of requested input
> columns. It allows for an implicit x coordinate value, but only in the
> case of 'plot ... using <y> with <something that only takes 2 cols>' 
> 
>   /* FIXME EAM - Trap special case of only a single 'using' column. */
>   /* But really we need to handle general case of implicit column 0 */
>         if (output == 1)
>             xpos = (axcol == 0) ? df_datum : v[axcol-1];
>         else
>             xpos = v[axcol];

Hmmm... then how did that work before EAM_DATASTRINGS?  I can't seem to 
find any similar snippet in 4.0 df_readline(). 

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.