Re: making element_type NDArray parent classes of element_type Matrix

[Carnë Draug]

On 5 November 2014 21:11, John W. Eaton <address@hidden> wrote:
> On 10/21/2014 07:00 PM, Carnë Draug wrote:
>>
>> Hi
>>
>> at the moment, both Matrix and NDArray classes are derived from
>> Array<element_type>.  I may be missing something but I think it makes
>> more sense to have the Matrix classes derive from a NDArray of the
>> corresponding element_type.
>>
>> For starters, I did this for boolMatrix and boolNDArray [1]. It is
>> building fine and make check is successful.  I would continue this but
>> maybe others have different opinions on what things should derive
>> from.
>>
>> There is also the case to have Matrix classes inherit from both an
>> AbstractMatrix and element_type NDArray, but that may complicate
>> things too much for very little gain (or any gain?).
>>
>> The specific thing that triggered this was trying to implement the
>> bitpack and bitunpack as boolNDArray methods [2].  That's when I
>> noticed that implementing on boolNDArray would not make it available
>> for boolMatrix
>>
>> Could anyone comment on this change?  If we are going to change where
>> things derive from, we may as well go for broke and make other bigger
>> changes that may have been hold back to not break existing code.
>>
>> Carnë
>>
>> [1] https://bpaste.net/show/6b5a03b8bda3
>> [2]
>> http://lists.gnu.org/archive/html/octave-maintainers/2014-10/msg00053.html
>>
>
> I think this is a reasonable change.  At the same time, we should ensure
> that Matrix objects always have 2 dimensions.  For example, we currently
> have
>
>   ComplexMatrix (const dim_vector& dv) : MArray<Complex> (dv.redim (2)) { }
>
> in ComplexMatrix.h but not in the bool and char Matrix equivalents.  The
> purpose of the redim function is to smash all dimensions higher than 2 into
> the second dimension.  For example if you used this constructor to create a
> ComplexMatrix with a dim_vector containing dimensions [2,3,4], you'd end up
> with a 2x12 matrix.  That makes sense given what typically happens with
> things like indexing (using rules we inherit for compatibility with Matlab).

Thanks for the feedback. I was wondering if there was any logic for the previous
organization, something that I was not seeing. I agree with using
redim but to start
I will just change the inheritance tree for the other types (will only
push when it is
all complete). Only then will I make changes that actually change the
dimensions.

Carnë