full/sparse/banded/triangular matrices...

[John W. Eaton]

On 30-Nov-2004, David Bateman <address@hidden> wrote:

| The risk is an explosion in the number of
| mixed operators. This is even more true if banded matrices are
| addressed at the same time.

Yes, we will need to come up with a systematic way of handling all
these so they can be generated automatically (at least as much as is
possible).

| There would also need to be a means of preserving, modifying or
| destroying the attribute during other operations. For example
| 
| UpperTriangular .* Full -> UpperTriangular
| UpperTriangular .' -> LowerTriangular
| UpperTriangular + Scalar -> Full

Wouldn't this last one only have to convert to Full if Scalar is
nonzero?  In that case, we really do want the storage class to be a
dynamic attribute of the array class instead of a fixed type attribute
that would be required if we had separate "top-level" classes for each
storage type.

| So longer term I see the best situation as having Array<T> evolve into
| something like
| 
| template <class T>
| class
| Array
| {
| protected
|   class FullRep
|   {
|     ...
|   };
| 
|   class SparseRep
|   {
|     ...
|   };

Yes, I think this is a good direction.  The rep classes don't have to
be nested, they are just handled that way now because it seemed good
to hide them.

I'm not sure that we want to define math operations on the Array
object, so the operators would be separate.

To be able to take advantage of external libraries like lapack, we
would probably need to be able to expose some details about the
internals (we do that already, with fortran_vec).

For efficiency, the operators would be defined on 

|   class BandRep
|   {
|     ...
|   };
| 
| public:
|   enum storage_type
|   {
|      DENSE,
|      SPARSE,
|      BANDED
|   };
|   enum attribute_type
|   {
|      UNKNOWN,
|      FULL,
|      UPPER,
|      LOWER,
|   };

Do we really need these enums?  Wouldn't you want to dispatch to the
rep class and have it do the right thing instead of using the enum
value?  It seems redundant to have both and switches are bad form in
C++ when a dispatch would do the job (think about the trouble caused
by the enum when you add a new rep type that requires a new enum value).

jwe