simplifying Array class hierarchy

[John W. Eaton]

On 20-Dec-2009, Jaroslav Hajek wrote:

| I'm working on a patch that should simplify the hierarchy of
| Array-descended classes. I hope to end with a simple tree
| Array -> MArray -> *NDArray -> *Matrix -> *{Column,Row}Vector
| 
| the rationale is that already now almost all the required
| functionality for 1D, 2D and nD arrays is contained within Array<T>,
| and the extra Array2, ArrayN classes mostly just complicate typecasts
| and cause more code duplication.
| So my idea is to move all 1D, 2D and nD methods to Array, and rebase
| the Matrix and Vector classes onto NDArray. A plausible consequence is
| that one will instantly be able to pass a Matrix or ColumnVector
| anywhere a NDArray is expected etc.
| 
| There are, however, a few minor problems with ambiguity if this should
| be done consistently. First, the resize method:
| 
| resize (octave_idx_type, const T&) // 1D with specified fill
| resize (octave_idx_type, octave_idx_type)  // 2D with default fill
| 
| these overloads become undistinguishable for T = octave_idx_type, and
| even for other types there may be an ambiguity if the fill value is
| not specified with an exact type, like
| Array<char> cha ...
| cha.resize (n, 1); // which one is called?
| 
| The cleanest solution I can think of is to remove Array<T>::resize
| (..., const T&) and only use resize_fill when a non-default fill value
| is required (almost never happens).
| Note that the type-specific subclasses can have these overloads back,
| e.g. ColumnVector will contain only these two:
| ColumnVector::resize (octave_idx_type)
| ColumnVector::resize (octave_idx_type, const T&)
| so there is no ambiguity.
| 
| I'd expect the impact to be low. However, virtually the same problem
| is with the constructor, i.e. I'd like to add
| Array<T>::Array (octave_idx_type, octave_idx_type) for consistency,
| and remove
| Array<T>::Array (octave_idx_type, const T&)
| Array<T>::Array (const dim_vector&, const T&)
| 
| and replace these by static methods. Again, the interface of NDArray,
| Matrix etc. can be retained, the only difference is that users won't
| be able to do
| Array<double> tmp (n, 0.0);
| but instead
| Array<double> tmp = Array<double>::filled (n, 0.0);
| 
| The situation is quite similar to dim_vector.
| Comments? Suggestions? Better solutions?

Sorry for the delay in responding.

I think these changes would be good.  Would you be able to check how
much code in Octave and Octave Forge is affected by the change?  I
would hope that not too much code written by users depends directly on
the Array class, but I have no way of knowing.  A quick grep of the
Octave Forge sources shows more direct uses of Array than I expected.

jwe