[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Matrices and "type tags"
From: |
A+A Adler |
Subject: |
Re: Matrices and "type tags" |
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 <address@hidden> 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, address@hidden
-----------------------------------------------------------------------
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
-----------------------------------------------------------------------