octave-maintainers
[Top][All Lists]
Advanced

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

Re: Design of N-D arrays


From: Petter Risholm
Subject: Re: Design of N-D arrays
Date: Thu, 7 Aug 2003 10:43:40 +0200 (MEST)

> I'm also wondering whether it really makes sense to have separate 2-d
> and N-d objects.  Maybe they should all be N-d.  Then we would have fewer
> types of objects to worrry about.
>
> Similarly, do we really need separate scalar objects?  The advantage
> of having them is that we can define special scalar x matrix (or N-d
> array) operations and if we also guarantee that all 1x1 matrix (or
> 1x1x...x1 N-d array objects) are automatically converted to scalars,
> then we don't have to check in the matrix x matrix operations for the
> special case of one argument being a scalar.  If we don't have them,
> then we do need to perform the check (which complicates the code for
> the operations), but we eliminate a lot of functions.
>
> Even if we eliminate the scalar and 2-d objects internally, we can
> still offer the same set of octave_value methods that we have now, for
> backward compatibility.
>
> Also, for complex vs. real, we currently have separate objects with a
> set of advantages and disadvantages similar to what we have for
> scalar/matrix/N-d array objects.  Maybe it would make more sense to
> have all array-like objects (structures, cells, function handles,
> etc. -- anything that needs to be N-dimensional) accessible in one
> container.  I'm not sure that the current set of classes is
> really the right organization for what we are trying to model.
>
> OTOH, maybe we don't need to eliminate the existing types, but we
> could modify the class hierarchy so that all the array-like objects
> could share a common interface (at least for a common subset of
> operations) and be manipulated as a single type of object (when the
> element and number of dimensions doesn't matter).
>
> jwe
>

Right now we are working on an implementation of N-D arrays based on
the previous mentioned design. Although it still needs some more work and
debugging, it shouldn't take too long to have it up and running
satisfactorily.
Currently, all the assignments (only for doubles) work but we haven't
implemented any N-D operations etc yet.

Implementing N-D arrays in a way such that we can eliminate scalar and
matrix classes seems to me to be a whole lot of work,
and perhaps it will be a waste of time to start doing that now
prior to the rewriting of the whole class hierarchy??

Should we decide to eliminate scalar and matrix classes, the N-D array
class will be huge. Doing all the conversions that are needed in the
current design, might not be any slower than using one class which has
code for scalars, matrices and N-D arrays?

Petter Risholm



reply via email to

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