[SciPy-user] Re: linalg.eig on sparse matrices
H Jansen
h.jansen at fel.tno.nl
Fri Jan 23 11:41:41 CST 2004
On Thu, 2004-01-22 at 20:54, Travis E. Oliphant wrote:
> H Jansen wrote:
> > One may want to have a look at pysparse:
> >
> > http://people.web.psi.ch/geus/pyfemax/pysparse.html
>
> Sparse matrices are definitely a candidate for SciPy. In fact, there is
> rudimentary support for Sparse matrices already there.
>
> The plan is to rewrite the Sparse matrix class into one (or more) Python
> type objects and support at least two different types of Sparse
> matrices: linked-list (for fast matrix formation), compressed sparse
> row (and compressed sparse column) for fast matrix manipulation. Four
> different data types are planned for these matrices.
>
> There is a project out there that gets a bit of the way there (I think
> it may be this one you speak of) but there is more to do to make it
> general purpose enough.
>
> If there are individuals out there with experience with Sparse matrices,
> this would be a great place to help out with development.
I can't consider myself a "sparse matrix specialist" but I'm eager to
test results and contribute to feature discussions. For instance, in
pysparse index information is not available so you can't iterate over
the sparse matrix elements --- this is a real handicap. Long time past
(in my Fortran days) I've used Yousef Saad's Sparsekit which, if I
remember correctly, was a pretty well featured sparse matrix kit. It
didn't come integrated with iterative solvers of course since
object-orientiation wasn't given much attention in the numerical
computing community at that time (late 80's, early 90's).
Things are now different, object-orientation has entered the numerical
computation field (see e.g. http://oonumerics.org, http://www.numpy.org
and many others ...). An interesting site (with article) is
http://dynopt.cheme.cmu.edu/roscoe/RTOp/ from which I gather that the
major challenge seems not to be a generic interface for dense and sparse
storage (and associated linear direct and iterative solvers) but
(1) the transparent (generic) and efficient access of
in-core/out-of-core vector/array data;
(2) the transparent (generic) and efficient access of distributively
stored vector/array data; and
(3) to facilitate efficient computation of (a growing number of)
application specific matrix/vector operations without the need to extend
the library with new methods.
In Python the "arrayfrombuffer" module may provide the functionality
needed for address (1). (... skipping issue (2) ...) In the article the
proposed solution for (3) is to have each numerical library implement
the "apply_op(...)" method which accepts user-defined (application
specific) matrix/vector operators. I believe the same solution can work
for Python: special-purpose vector/matrix operations can be implemented
in a compilable language (Fortran/C++) and easily be interfaced with
Python (using, for example, for Fortran: F2PY or pyfortran, and for C++:
C++boost template library, PyCXX or Swig).
These were just some ideas,
-Henk
>
> -Travis Oliphant
>
> _______________________________________________
> SciPy-user mailing list
> SciPy-user at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-user
--
Henk Jansen <h.jansen at fel.tno.nl>
TNO Physics and Electronics Laboratory
--
------------------------------------------------------------------------------
The disclaimer that applies to e-mail from
TNO Physics and Electronics Laboratory
can be found on: http://www.tno.nl/disclaimer/email.html
------------------------------------------------------------------------------
More information about the SciPy-user
mailing list