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

Robert Cimrman cimrman3@ntc.zcu...
Thu Jan 3 04:06:59 CST 2008


Nathan Bell wrote:
>> 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?

Yeah, even an older version would be good. But as every version gets 
(significantly) faster than the previous ones, a scikit should exist for 
the latest version.

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

This could be a good project for a student to find out...

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

DummyMatrix/DummySparseMatrix then? I am bad at inventing names.

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

SparseEfficiencyWarning is perfect! Thanks for adding this.

r.


More information about the Scipy-dev mailing list