octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

simplifying Array class hierarchy


From: Jaroslav Hajek
Subject: simplifying Array class hierarchy
Date: Sun, 20 Dec 2009 12:04:00 +0100

hi all,

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?

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz


reply via email to

[Prev in Thread] Current Thread [Next in Thread]