[Numpy-discussion] Matrix Class [was numpy release]
Bill Spotz
wfspotz@sandia....
Tue Apr 29 07:50:22 CDT 2008
On Apr 29, 2008, at 2:50 AM, Robert Cimrman wrote:
> FYI:
> In scipy, the iterative solvers (cg and like) should work with
> LinearOperator (a class with matvec, rmatvec, and eventually matmat
> methods) passed instead of the A matrix argument. There is a function
> aslinearoperator() is scipy.sparse.linalg, that constructs a
> LinearOperator instance from a numpy array, matrix and scipy sparse
> matrix. It could be generalized to accept a function for a matrix-free
> computation, too. Also LinearOperator.__mul__, __rmul__ could be
> easily
> defined via matvec, rmatvec.
>
> IMHO the all iterative solvers could use such a concept, to shield
> them
> from what the system matrix A or the preconditioner actually are and
> to
> be able writing them in a visually appealing way (i.e. close to what
> one
> writes on a paper).
I agree. This is very close to what we use in Sandia's C++ Trilinos
project: http://trilinos.sandia.gov. The linear algebra services
package (Epetra: http://trilinos.sandia.gov/packages/epetra) supports
the following class hierarchies:
Epetra_Operator <- Epetra_RowMatrix <- Epetra_CrsMatrix
Epetra_MultiVector <- Epetra_Vector
(Where "Crs" stands for "compressed row storage"). A typical solver
package (e.g. AztecOO: http://trilinos.sandia.gov/packages/aztecoo)
defines solver routines that take an Epetra_Operator for A (and
preconditioner P) and an Epetra_MultiVector for b and x. The most
common way to call them is with an Epetra_CrsMatrix and an
Epetra_Vector, but the flexibility is there.
** Bill Spotz **
** Sandia National Laboratories Voice: (505)845-0170 **
** P.O. Box 5800 Fax: (505)284-0154 **
** Albuquerque, NM 87185-0370 Email: wfspotz@sandia.gov **
More information about the Numpy-discussion
mailing list