[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day
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.
More information about the Scipy-dev