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

[Ethan A M. <merritt@u.washington.edu>]

On Saturday 10 July 2004 05:20 pm, you wrote:

This is going to be a long explanation, so please bear with me.

> 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

Right.  df_readline() fills in a vector v[] whose elements are in
order of the requested data items.
The datastrings patchset added a parallel vector df_tokens[]
whose elements point instead to a string representing the
particular requested data item.  get_data() can use these
to fill in the 'data points' in the '[s]plot ... with labels' style.

So far, so good.  Then it gets a bit messier because the new code
also handles entities such as an in-line plot title or tic labels, 
and the lines below are part of that.

> >   /* 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().

For completeness sake, let me explain what this code is doing:

At this point in the code we know that the string value we are looking
at is supposed to be an axis tic label.  We also know which axis it is
a tic label for. We want to create a pair ["ticlabel", axis-value]  just
as in  a 'set [xyz]tics { "label" pos, ...}' command.  But which input 
column contains the value for that axis?  That is, if we are reading
a ytic label, how do we know which column contains y?  

Problem #1: Most of the plot styles are consistent in that the first
column is x, the second column is y, and the third column is z.
But the 3D plot modes can violate this order and in particular, as I
mentioned before, it is problematic which column will be used to
generate a color value. Given that there is not currently any way
to tell what the plot style is (or even if it is 3D) all I can do is 
hope that the x:y:z order holds. But currently   
'plot ... using ...cbticlabels(<n>)' doesn't work, because there is
no way to know which column the color info is in without
access to more information about the plot.

Problem #2:  The mapping of columns 1:2:3 to x:y:z coordinate value
is broken by the use of implicit x coordinates.  Consider the command
'plot ... using 2:yticlabel(1)'.   In this case the  first (and only)
column contains a y coordinate rather than an x coordinate.
Since no currently supported plot styles really use only a single
input coordinate, it is easy to detect this simple case, and that is
exactly what the code section extracted above is doing.

The code is marked FIXME because it cannot detect, let alone deal
with, any more complicated cases where the order of axes cannot be
deduced from the number of columns.   In practice this is not much
of a limitation, though eventually someone is bound to trip over
it and report it as a bug.  If it becomes important to handle the
oddball cases as well, then I think it will be necessary to have
access to the current plot and style information.  That is why I
used it as an example of wanting a pointer to the current plot.

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle