dynamic axex [was Re: with parallelaxes dumps core]

[Ethan A M. <sf...@us...>]

On Monday, 26 January, 2015 19:28:19 Philipp K. Janert wrote:
> 3) The limitation to 7 cols (which, I
> suspect, depends on limitations in the
> way "using" is parsed) puts the entire
> plot style into question.

Somewhat tangential, but here goes.

There are 3 related but distinct limitations:

1) The number of columns read from a data file.
   This is essentially unlimited.  For example:
   plot 'data' using 0:(sum [i=1:999] column(i))
   will happily read 999 columns of input data

2) The number of properties associated with a
   single "point" in a plot.  This is currently 8:
      x y xlow xhigh ylow yhigh z color 
   The first 7 are fields in (struct coordinate).
   The 8th is kept in a separate location, but only
   if the plot involves variable (i.e. per-point) color.

3)The number of fields in a "using" specifier.
  This is currently defined by
     #define MAXDATACOLS (MAX_NUM_VAR+2)
  and is primarily relevant to the "fit" command


However, none of these are the reason for a cap on the number
of parallel axes.  That comes instead from a poor design
decision now lost in the mists of program history.
There is one "struct axis" for each axis holding the
range limits, scaling,  tic information, axis labels, etc.
That's fine.

But the axis parameter passed to all the subroutines
and macros that manipulate this data is not a pointer to
an instance of an axis structure, but instead an index into
the fixed array
    struct axis axis_array[AXIS_ARRAY_SIZE]
This is bad, because you can't just allocate a new
axis structure and pass it to any of the existing 
subroutines or macros.

So the first step towards allowing dynamically allocated
axes has to be refactoring all the code to use an axis
pointer rather than an array index.  Not terribly
difficult, but it touches a huge amount of code.
I think this would be a nice cleanup, but until now
there has not been sufficient motivation to tackle it.

	Ethan