[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day
Wed Jan 2 14:37:33 CST 2008
On Jan 2, 2008 4:03 AM, Robert Cimrman <firstname.lastname@example.org> wrote:
> IMHO iterative solvers (eigen- or linear) do not care about the format
> of matrices they work with - all they need is the matrix action on a
> vector. Due to this I think they do not belong under scipy.sparse - they
> should work without change for dense matrices, or even for matrix-like
> objects that have only the matrix action (A*x) implemented. lobpcg.py
> works like that already - a user can pass in a dense/sparse matrix or a
> +1. Maybe instead of 'iterative' I would use something like
> 'isolve(r(s))' to indicate their purpose better.
Travis suggested creating scipy.splinalg to include the sparse solvers
and other functionality. We could have:
splinalg.factor -- direct factorization methods (e.g. SuperLU)
splinalg.eigen -- sparse eigensolvers (e.g. ARPACK, lobpcg)
splinalg.solve -- sparse solvers for linear systems (e.g. CG, GMRES)
In the process we'd eliminate scipy.linsolve and
scipy.linalg.iterative and move that code to splinalg.factor and
splinalg.solve respectively. We could then draw a distinction between
scipy.linalg -- dense linear algebra and splinalg -- sparse linear
algebra. We could then move sparse functions spkron and spdiags to
splinalg.construct or something like that.
I'm not married to any of the names above, so feel free to offer alternatives.
I agree with your statement that such solvers should not be
exclusively for sparse matrices. However it's important to set them
apart from the dense solvers so new users can find the most
appropriate solver for their needs.
We should also explore the idea of having a scipy.gallery in the
spirit of MATLAB's gallery function. This would be extremely helpful
in illustrating non-trivial usage of the sparse module (in tutorials
and docstrings) and would facilitate more interesting unittests. Any
Nathan Bell email@example.com
More information about the Scipy-dev