octave-maintainers
[Top][All Lists]
Advanced

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

Re: nd-arrays


From: John W. Eaton
Subject: Re: nd-arrays
Date: Wed, 17 Sep 2003 16:14:28 -0500

On 12-Sep-2003, John W. Eaton <address@hidden> wrote:

| On 12-Sep-2003, Petter Risholm <address@hidden> wrote:
| 
| | I like your idea of eliminating Array2.
| | I guess that means that we will still have MArray2, but instead of
| | inherinting from Array2 it inherits from ArrayN.
| | 
| | As a start, I've moved and modified assign, maybe_delete_elements etc from
| | Array2-idx.h to ArrayN-idx.h so that if n_idx and lhs_dims.length <=2 we
| | use the 2d version of assign.
| | 
| | In addition I've had to move som functions from Array2 to ArrayN such as
| | elem( int, int), resize (int, int) etc.
| 
| Perhaps I'm missing something, but I don't think there's any need to
| move those functions just yet.
| 
| | Eventually we will have to rewrite the code to use elem (Array<int>), but
| | it might at least be a starting point.
| | 
| | by applying the operator patches, the 2d part of octave should behave
| | stable since we always use the 2d assign whenever there are 2 indices (or
| | fewer).
| | 
| | These changes could be the first step towards eliminating Array2, I do not
| | know if there's any point in applying them to the CVS version yet.
| | 
| | Have I misunderstood what you meant in the previous mail, or is this
| | somewhat how you imagined doing it??
| 
| My starting point was going to be changing the internal
| respresentation of the octave-base-matrix object to be an ArrayN
| object instead of a 2-dimensional object.  Likewise for any objects
| derived from octave-base-matrix.  The public interfaces would be
| extended to accomodate N-dimensional arrays, but the existing
| functions would continue to work as before.  Any requests for
| 2-dimensional objects would be the same as before.  Very little other
| code would have to change, at least at the beginning of the
| transition.  But I could be missing some detail that would force a lot
| more changes than I'm expecting.  I think I should try my ideas and
| see how they work out.

I started working on these changes last Friday and now I have something
that is mostly working.  Instead of

               Array <--- Marray <--- RowVector, etc.
                 ^
                 |
        +--------+
        |        |
        |        |
      ArrayN   Array2 <--- Marray2 <--- Matrix, etc.
        ^        ^
        |        |
     MArrayN   Array3
        ^
        |
     NDArray, etc.


(arrows point toward the base class) we now have


     Array <--- MArray <--- RowVector, etc.
       ^
       |
       +------- Array2 <--- MArray2 <--- Matrix, etc.
       |
       +------- Array3
       |
       +------- ArrayN <--- MArrayN <--- NDArray, etc.


so the Array class itself is multidimensional and the Array2 and
Array3 classes are just special cases of that.  The ArrayN class
probably isn't actually needed, but I've left it there for now.

The interfaces of the RowVector, Matrix, etc. classes have not
changed.  The interface for Array has changed, but I think the changes
are backward compatible.

I've modified the octave_matrix object so that is based on the NDArray
object instead of the Matrix object.  I'll do the same for the
octave_complex_matrix object, then also cell and structure arrays so
they will become N-dimensional.

Quite a few changes were required (more than I expected).  In the end,
I touched the following files:

  liboctave/Array-C.cc
  liboctave/Array-b.cc
  liboctave/Array-ch.cc
  liboctave/Array-d.cc
  liboctave/Array-flags.cc
  liboctave/Array-i.cc
  liboctave/Array-idx.h
  liboctave/Array-s.cc
  liboctave/Array.cc
  liboctave/Array.h
  liboctave/Array2-idx.h
  liboctave/Array2.cc
  liboctave/Array2.h
  liboctave/Array3-idx.h
  liboctave/Array3.cc
  liboctave/Array3.h
  liboctave/ArrayN-idx.h
  liboctave/ArrayN-inline.h
  liboctave/ArrayN.cc
  liboctave/ArrayN.h
  liboctave/CColVector.h
  liboctave/CDiagMatrix.cc
  liboctave/CMatrix.cc
  liboctave/CRowVector.h
  liboctave/DiagArray2.cc
  liboctave/DiagArray2.h
  liboctave/MArray-d.cc
  liboctave/MArray-defs.h
  liboctave/MArray.h
  liboctave/MArrayN.cc
  liboctave/MArrayN.h
  liboctave/MDiagArray2.h
  liboctave/Makefile.in
  liboctave/dColVector.h
  liboctave/dDiagMatrix.cc
  liboctave/dMatrix.cc
  liboctave/dNDArray.cc
  liboctave/dNDArray.h
  liboctave/dRowVector.h
  liboctave/mx-base.h
  liboctave/mx-inlines.cc
  liboctave/str-vec.h
  src/data.cc
  src/file-io.cc
  src/oct-obj.h
  src/ov-base-mat.cc
  src/ov-re-mat.cc
  src/ov-re-mat.h
  src/ov-re-nd-array.cc
  src/ov-scalar.h
  src/ov-typeinfo.h
  src/ov.cc
  src/pr-output.cc
  src/pr-output.h
  src/utils.cc
  src/utils.h
  src/TEMPLATE-INST/Array-tc.cc

(some of these files may no longer be needed).

I think I like the new way better.  If you'd like to see the diffs, I
can post them somewhere before I check them in.  Otherwise, if there
are no objections, I'll check in my changes soon, probably within the
next day or so.

jwe



reply via email to

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