From help-octave-request at bevo dot che dot wisc dot edu  Fri Dec 10 19:57:17 1999
Subject: Re: Matrices and "type tags"
From: A+A Adler <adler at mondenet dot com>
To: help-octave at bevo dot che dot wisc dot edu
cc: help-octave <help-octave at bevo dot che dot wisc dot edu>
Date: Fri, 10 Dec 1999 21:11:26 -0500 (EST)

On Thu, 9 Dec 1999, John W. Eaton wrote:
> On  9-Dec-1999, Jon Wilkening <wilkenin at math dot lbl dot gov> wrote:
> | Perhaps instead of type-tags and the
> | all-purpose backslash there should be a family of less elegant
> | commands that give more control over how the system is solved.
> | (Maybe there are such commands already?)

This is something that I've been thinging about while writing
the sparse functions. The underlying library I'm using is
SuperLU - which provides a basic sparse solve function as
well as what they call their "expert" solver.

This "expert" function gives all sorts of options to do
fancy thing with row/column reordering, memory management,
iterative refinement and more.

In this case the easiest thing for me to do is have

   A\b -> use the basic solver
and write a new function
   sparsesolve( A, b, options) to use the "expert" solver

However, if someone could invent a common sheme to 
encapsulate these extra-functionality solve routines,
then I would write it to that spec.


> Octave currently represents matrices internally by using different
> classes.  Complex and real are all that are really used now, but there
> are diagonal matrix classes in liboctave, and I think we will soon
> have a sparse matrix class too.  I'm considering adding banded matrix
> classes, and perhaps triangular (trapezoidal?) myself.  Once those are
> in place, I think the correct thing for Octave's value object to do is
> to to convert to specific types when appropriate (similar to the
> complex to real conversion that currently occurs if all imaginary
> parts of a complex matrix become zero).  Then the appropriate
> operation for a matrix could be performed depending on its class.

Wouln't this require plenty of logic everytime a new matrix
is created to figure out which class it belongs to. For
example with

   a= rand(10);
   b=a+a';

now octave would have to check b to see whether it is 
symetric or not. This could end up being quite a performance
hit.

Since there are more matrix creations than solve operations,
it seems to me more efficient to check for special structure
during the solve rather than at matrix creation.

Additionally, on average it will only take a few operations
to determine that a matrix is not symetric, however, it would
require checking the whole matrix to verify that it is.

______________________________________________________________
Andy Adler,                               adler at mondenet dot com



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------