! 8 Dimensional (or so) AnalytiCalc   G This document is meant to describe some of how a variant of AnalytiCalc 4 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 4 be up to some reasonable limit (7 or 8, let's say).   @ A command would be added to define dimensionality of the matrix,B so it might be done inside the S command (where questions are freeJ form), and could ask for dimensions (col, row, page, hyperpage, superpage,H ...) of the equivalent storage area. The actual storage would be ALIASEDC by these dimensions and cells could be referenced as something like    P#(d1,d2,d3,d4,d5...)   A 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.  A Command syntax would need to have added options mainly in XQTCMD. . Ranges would need the ability to be spec'd as:  A V1;V2:V3 instead of only V1:V3. This would mean that the interval A 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 makeH 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.   G Ranges of 3-cell types would have to be supported inside multi-argument / functions as well as the present 2-cell ranges.   6 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 valueE 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...  G N.B. - It may be important to support this for only 4 or so dimensions, 3 whose sizes could be (on a sheet of 80 by 400 size)   . 20 col by 50 rows by 8 planes by 4 hyperplanes  6 	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 cellsB P#(d1,d2,d3,...) follows from the fact that dimensions are treatedA "equally" and where there are more than two, the <letter><number>  paradigm does not help.  	Glenn Everhart 8/13/1987   