Re: matrix type caching, triangualar and Cholesky solvers

[John W. Eaton]

On 30-Apr-2006, David Bateman wrote:

| Ok, here is a better version of this patch that combines the SparseType
| and MatrixType classes into a single class, and creates a virtual
| function matrix_type in octave_base_value to overcome the need of
| dynamic casting to a type before calling the matrix_type function as in
| the previous patch.
| 
| John, up to you if you want me to check it in, as it doesn't look like
| it'll get any testing apart from my own till it is, check it in might at
| least get some testing :-)

I think it is good to use optimized routines for various matrix
types, so I think we need something like this.  OTOH, the thing I
don't like about the current solution is all the places where we now
have things like

   if (typ == MatrixType::Upper)
     retval.typ = MatrixType::Lower;
   else if (typ == MatrixType::Permuted_Upper)
     retval.typ = MatrixType::Permuted_Lower;
   else if (typ == MatrixType::Lower)
     retval.typ = MatrixType::Upper;
   else if (typ == MatrixType::Permuted_Lower)
     retval.typ = MatrixType::Permuted_Upper;
   else if (typ == MatrixType::Banded)
     {
       retval.upper_band = lower_band;
       retval.lower_band = upper_band;
     }

In the future, if another type is added, we have to hunt for all of
these if blocks/switch statements.  If the type information was
handled by subclassing the Matrix object and using virtual methods,
then we could avoid this problem.  Using a virtual method also allows
external user code to benefit from new types without necessarily
having to change.

OTOH, that might be a lot of work, and if the number of places where
we have to check matrix type is small, it might not be worth it.

I'd say check it in if you think the future maintenance won't be too
bad and that using a virtual method solution would be more effort than
it is worth for this problem.

jwe