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

Ondrej Certik ondrej@certik...
Wed Jan 2 14:51:41 CST 2008


On Jan 2, 2008 9:50 PM, Ondrej Certik <ondrej@certik.cz> wrote:
>
> 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)

and blzpack - that one is BSD, so it could even go to scipy.

Ondrej


More information about the Scipy-dev mailing list