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

[Nathan Bell]

On Jan 3, 2008 3:18 AM, Robert Cimrman <cimrman3 at ntc.zcu.cz> wrote:
> Maybe the contruction functions could live directly in the splinalg
> namespace?

That's possible.  I can only think of a few functions, so a submodule
is probably unnecessary.

> 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...

I think it would make a good scikit.

It seems highly unlikely that Tim Davis would make a license change
for us, but it's worth asking.  Perhaps he'd put an older version in
the public domain?

Are there BSD licensed sparse LU codes that are superior to SuperLU?

> 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?

Currently, the iterative solvers only require a matvec(x) method and
perhaps a .shape attribute.  I suppose you mean a class:
   MatrixAction(matvec, shape, rmatvec=None)
that's essentially a dummy object which satisfies our expectations in
the sparse solvers?  I added rmatvec because some iterative solvers
require matrix vector products by the transpose.

I'm not keen on the name, but the idea is quite good.  It's easier to
document MatrixAction once than describing the expected interface
(i.e. .matvec() and .shape) in each iterative solver's docstring.


> 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.

I've added a SparseEfficiencyWarning for people who construct matrices
using the CSR/CSC formats.  I suppose we could do something similar
for functions which expect a particular format.

Should we use SparseEfficiencyWarning for this situation, or should a
new Warning be created?


-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/