Re: nd-arrays

[John W. Eaton]

On  9-Sep-2003, Petter Risholm <address@hidden> wrote:

| I can not come up with a clean way to have octave  decide if we should
| convert to a
| matrix or a nd-array before doing the inital assignment.

It should be possible to make this happen using a combination of
empty_conv (defined in the octave_value class hierarchy) and widening
ops (part of the typeinfo code, and defined in the files in the
src/OPERATORS directory.

As things are now, we would need to extend the idea of widening ops to
also handle the case of needing to widen a matrix to an N-d Array
(presumably only if the number of indices for the LHS of an assignment
is greater than 2).  I don't really like this solution all that much
becuase it does seem like a bit of a kluge.  Also, I can now see that
having both Matrix and N-d Array objects in the octave_value class
hierarchy will lead to quite a bit of duplicated code.  I think it
might be better to rewrite the code in ov-base-mat.cc so that it can
handle N-d Arrays and then convert the real, complex, char/string, and
other full matrix types to use N-d Arrays.  There will be much less
duplication if we do this.  These classes can still provide
matrix_value, complex_matrix_value, etc. methods that return Matrix
and ComplexMatrix objects.  Doing so will only require copying a
pointer and some dimension information, so it is not much overhead.
But internally, all Octave array objects will be derived from the
ArrayN class.  Maybe eventually the Matrix and ComplexMatrix objects
will also be derived from them (so instead of going from Array to
Array2, we will just have ArrayN and everything else will be a special
case of that).

Although this is a pretty fundamental change in the way Octave works,
I don't think all that much code will need to change because
the octave_value type (and the subclasses octave_matrix and
octave_complex_matrix) will continue to work as before, but now they
will also be able to handle N-d arrays.  All the code that extracts
Matrix or ComplexMatrix values from octave_values, and all code that
uses those types will continue to work just as it does now.

Also, when there is only one or two indices and 2 dimensions, we can
continue to use the same code that we do now for indexing and doing
indexed assignments, so I don't think it will make Octave less
reliable in the short term.

Comments?

BTW, I think you have gained a very good understanding of the
octave_value type and the way the core of Octave works.  Probably you
understood it better than I did earlier today because it took some
time for me to understand exactly how Octave handles type conversions
in indexed assignments.

Don't worry about it if you don't see how this might be implemented
easily.  I think I see how it can be done, so maybe I should work on
this for a few days and try to make it work.

Thanks,

jwe