[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day
Wed Jan 2 14:51:41 CST 2008
On Jan 2, 2008 9:50 PM, Ondrej Certik <firstname.lastname@example.org> wrote:
> 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
> > comments?
> 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)
and blzpack - that one is BSD, so it could even go to scipy.
More information about the Scipy-dev