[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day
Wed Jan 2 14:50:52 CST 2008
On Jan 2, 2008 9:37 PM, Nathan Bell <email@example.com> 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
> > function.
> > +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
No comments, just agree with everything you said.
Actually one comment - how could one plug more solvers to the above
(pysparse comes to my mind)
More information about the Scipy-dev