Re: with parallelaxes dumps core

[Philipp K. J. <ja...@ie...>]

[snip]

> > One comment, though: before going down this
> > path (of extending the permissible number of
> > cols in "using") very far, let's consider
> > whether this is the right way to do it.
> >
> > Already, entering 7 explicit col numbers is a
> > pain. Entering 35 (or whatever) different ones
> > is simply not practical.
> 
> Well, as with binary data, it could be that the data file and the 
> command itself are constructed by automation, i.e., a computer
> program or script.  Plus, it isn't that difficult to build up a long
> command in an input file using an editor.
> 

Maybe so, but I really consider it a mistake
to rely on it, ie: designing the UI under
the assumption that the user automates.

> 
> > Should the whole approach be rethought? Is
> > "plot" even the right command? I'd argue (not
> > having looked at the implementation) that we
> > should consider "splot", because splot naturally
> > deals with data on a rectangular grid (matrix data).
> 
> I'm not sure a rectangular grid is any type of requisite.  From the 
> documentation, it sounds like the parallelaxes is a means to visually 
> show correlation between disparate measurements.  That is, if there
> are strong color bands, I assume that is more correlation, be it
> positive or negative.
> 

Yes, it is a prereq. The idea is that you have a 
number of records, with each record having multiple
measurements. It is a safe (but not guaranteed)
assumption that each record has the same number
of measurements. (If this is not true, parallel
axis plots don't really apply - edge cases 
notwithstanding.)

> 
> > And that's exactly the type of data used for
> > parallel axes plots. Put another way: splot
> > already handles dynamic rows AND columns.
> 
> It actually may be its own type of plot, neither "plot" nor "splot". 

Ok, point well taken. From looking at the way it
currently works, I assumed that there was a desire to 
"piggy-pack" parallel axis on existing infrastructure.
If so, then splot might be a better starting point.

But if that's not the guiding principle, then parallel
axis should not be treated as an isolated type, but 
merely as a special case of multidimensional plots in
general. At the very least, they should be able to handle
polar coordinates together with "parallel axes" ("star plots").

>  From what Ethan describes, I'm guessing that the data file is
> re-read once for each axis to get the column of data that is to
> appear on the axis.  In some sense it's a one-dimensional plot, isn't
> it?  That is, the data only appears on one axis only and it is simply
> that there are many axes.  So, some analogous terms might be:
> 
> plot   ->  plot2d
> splot  ->  plot3d
> paxis  ->  plot1d
> 
> We can think of plot2d being a subset of plot3d, with a viewing angle 
> that's orthographic.  We can think of plot1d as being a subset of 
> plot2d, again with a viewing angle that eliminates one of the 
> dimensions.  But parallel axes is some kind of new creature,
> basically connecting points across multiple plots.  In theory it
> could be done with 2d and 3d plots, but would be a mess to look at of
> course.  So, parallelaxis is more along the lines of "multiplot",
> isn't it?  Should it's syntax fall more along that lines?  E.g.,
> 
> set parallelaxis layout 7,1

I think this is going in a similar direction to what I
said earlier - treat it as its own beast, but more 
generally. The idea of hitching onto the "multiplot"
features strikes me as interesting. That might deliver
the "star plot" application for (almost) free, by the way.

> 
> Dan