8 Dimensional (or so) AnalytiCalc

This document is meant to describe some of how a variant of AnalytiCalc
that supports multi-dimensional access might appear.

Basically, the existing storage can be handled, not only as a 2
dimensional array, but as an n dimensional one, where n may
be up to some reasonable limit (7 or 8, let's say). 

A command would be added to define dimensionality of the matrix,
so it might be done inside the S command (where questions are free
form), and could ask for dimensions (col, row, page, hyperpage, superpage,
...) of the equivalent storage area. The actual storage would be ALIASED
by these dimensions and cells could be referenced as something like

P#(d1,d2,d3,d4,d5...)

by modifications to VARSCN (and probably nowhere else) (if use of
"(" and ")" causes trouble then the "{" and "}" chars could be
substituted without messing much up, I think. But I'd try normal
parens first.
	The usual Fortran type formulas for computing a one dimensional
alias address could be used.

Command syntax would need to have added options mainly in XQTCMD.
Ranges would need the ability to be spec'd as:

V1;V2:V3 instead of only V1:V3. This would mean that the interval
between V1 and V2 would specify the increment of the cells to use
(permitting generalized diagonals) and V3 would be the last cell
(or a limit cell) to be used.
	A fair amount of XQTCMD logic needs to be altered to make
this work. At least the following commands would be needed: (in addition
to what comes free by the VARSCN mod)

CR inrange outrange		; with multidim. ranges
OAM and ORM cell;cell;cell	; Specifies to set part of display
	; to point to a hyperplane of cells specified by the three-cell
	; range, where the cells would define a plane (being at three
	; corners of the plane, so the command
 OAM A1,B1,A2
	; would be equivalent to 
 OA A1
	; exactly.

Ranges of 3-cell types would have to be supported inside multi-argument
functions as well as the present 2-cell ranges.

DF c1;c2:c3  [format]  would have to be supported too.

PP and GP functions could be used as is (restricting generality)
and the dimensions would need a usually-adequate default value
set. However, dimension aliases need to be saved/restored. This means
at least minor alterations in save format.

	Possibly consideration of 2 dimensional sums etc. should be
taken too...

N.B. - It may be important to support this for only 4 or so dimensions,
whose sizes could be (on a sheet of 80 by 400 size)

20 col by 50 rows by 8 planes by 4 hyperplanes

	This appears pretty modest, but is a LOT of cells and
likely to be useful.

	One would want to ensure that the number of cells generated
by the dimensions given fit in the storage available. This could
be built into the S option questions. The notation for cells
P#(d1,d2,d3,...) follows from the fact that dimensions are treated
"equally" and where there are more than two, the <letter><number>
paradigm does not help.
	Glenn Everhart 8/13/1987