[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day

Ondrej Certik ondrej@certik...
Wed Jan 2 14:50:52 CST 2008


On Jan 2, 2008 9:37 PM, Nathan Bell <wnbell@gmail.com> wrote:
> On Jan 2, 2008 4:03 AM, Robert Cimrman <cimrman3@ntc.zcu.cz> 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
> comments?

No comments, just agree with everything you said.

Actually one comment - how could one plug more solvers to the above
architecture?
(pysparse comes to my mind)

Ondrej


More information about the Scipy-dev mailing list