octave-maintainers
[Top][All Lists]
Advanced

[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


reply via email to

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