[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day
Thu Jan 3 03:18:05 CST 2008
Nathan Bell wrote:
> 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.
Maybe the contruction functions could live directly in the splinalg
> I'm not married to any of the names above, so feel free to offer alternatives.
The names are good.
Now what to do with umfpack? The current situation when the wrappers are
in linsolve and the solver is external is not ideal. I did it this way
at time when there were no scikits and SuperLU solver included in scipy
had not performed well for my matrices. Would it be a good scikit? Or we
could contact Tim Davis...
Like Ondrej said, more solvers are always needed.
> 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.
Yes, it makes sense to separate dense and sparse solvers, at least until
there is some notion of a sparse matrix in numpy and most relevant
functions work for 2D dense arrays, dense matrices and sparse matrices.
We could make a new sparse matrix-like class, which just implements a
matrix action via a user-specified function. Is the name MatrixAction ok?
Many solvers expect a particular sparse matrix format. Apart from the
fact that this should be properly documented, I would like to issue a
warning when an implicit conversion of a sparse format occurs. This
could be controlled by some warning-level or verbosity parameter.
> 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
I am sure Nils Wagner has lots of interesting matrices to test
More information about the Scipy-dev