Design of N-D arrays

[John W. Eaton]

On  6-Aug-2003, Petter Risholm <address@hidden> wrote:

| Files in ./src/OPERATORS/op-* define different assign conversions. For
| instance in op-s-s.cc where an assignment with a scalar on both the left
| hand side and right hand side is defined to result in a matrix. The
| resulting matrix is mutated back to a scalar if it is a 1x1 matrix.
| 
| By using and expanding this design to work for N-D arrays, we will need to
| make all assignments result in a N-D array and then mutate it back to a
| scalar or matrix if the result should turn out to be of 1 or 2 dimensions.
| 
| A drawback with this design is the overhead created by all the
| conversions, and the fact that N-D arrays need to implement code to do
| assignments for both scalars and matrices in addition to higher
| dimensions.
| 
| It might be possible to change some of the macros to see how many
| indices/dimensions lhs and rhs have and thereby possibly avoid the
| conversions.
| 
| Comments are appreciated!

I'm also wondering whether it really makes sense to have separate 2-d
and N-d objects.  Maybe they should all be N-d.  Then we would have fewer
types of objects to worrry about.

Similarly, do we really need separate scalar objects?  The advantage
of having them is that we can define special scalar x matrix (or N-d
array) operations and if we also guarantee that all 1x1 matrix (or
1x1x...x1 N-d array objects) are automatically converted to scalars,
then we don't have to check in the matrix x matrix operations for the
special case of one argument being a scalar.  If we don't have them,
then we do need to perform the check (which complicates the code for
the operations), but we eliminate a lot of functions.

Even if we eliminate the scalar and 2-d objects internally, we can
still offer the same set of octave_value methods that we have now, for
backward compatibility.

Also, for complex vs. real, we currently have separate objects with a
set of advantages and disadvantages similar to what we have for
scalar/matrix/N-d array objects.  Maybe it would make more sense to
have all array-like objects (structures, cells, function handles,
etc. -- anything that needs to be N-dimensional) accessible in one
container.  I'm not sure that the current set of classes is
really the right organization for what we are trying to model.

OTOH, maybe we don't need to eliminate the existing types, but we
could modify the class hierarchy so that all the array-like objects
could share a common interface (at least for a common subset of
operations) and be manipulated as a single type of object (when the
element and number of dimensions doesn't matter).

jwe