[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
proposal for changing Array interface
From: |
Jaroslav Hajek |
Subject: |
proposal for changing Array interface |
Date: |
Thu, 21 Jan 2010 07:37:16 +0100 |
hi all,
after some more thinking about the problems, I propose the following:
1. Remove the Array<T>::Array (octave_idx_type) and Array<T>::Array
(octave_idx_type, const T&) constructors.
2. Remove the dim_vector::dim_vector (octave_idx_type) constructor.
3. Rename Array<T>::resize (octave_idx_type) and resize
(octave_idx_type, const T&) to resize_1d.
Rationale:
1. Each Array has always at least 2 dimensions, so these would-be 1D
constructors are in fact 2D, only n is promoted to n, 1. It's not
particularly clear.
1a. The second constructor in 1 prevents a clean definition of a 2D
constructor Array (octave_idx_type, octave_idx_type), because of the
conflict for T = octave_idx_type.
2. like 1. dim_vector (octave_idx_type) bites.
3. Similar to 1a, this prevents a clean definition of 2d resize (which
is more useful imho). Besides, contrary to intuition, resize (n) does
*not* behave like resize (n, 1) but rather like resize (1, n) and
fails for actual nonempty 2D arrays - it mainly exists to handle
out-of-bounds linear assignments. I would prefer to hide this method
as it is inconsistent with all the rest.
With these changes, it should be possible to cleanly remove the
MArray2 and MArrayN classes and make all Matrix, Vector and NDArray
classes inherit from MArray, which should facilitate simpler
conversions and reduce code duplication.
These changes will obviously break compatibility.
comments?
--
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
- proposal for changing Array interface,
Jaroslav Hajek <=