[SciPy-dev] Sparse matrix module
cimrman3 at ntc.zcu.cz
Tue Oct 25 03:56:54 CDT 2005
Travis Oliphant wrote:
> Ed Schofield wrote:
>>Robert Cimrman wrote:
>>>I am personally in favor of the TravisSparse approach as the base with
>>>RomanSparse subclass of spmatrix with a key feature "*speed* *speed*
>>>*speed*". Also the _solvers_ should be split as much as practical from
>>>the sparse matrix _type_. Of course, having some 'recommended format
>>>hinting' (e.g. CSR for umfpack), that would tell the user "use this if
>>>you want speed and to avoid implicit matrix conversion" would be
> This is already the case. Currently the CSC type is used for SuperLU
> decomposition, and any matrix with a matvec method can be used with the
> iterative approaches.
Great. (In my remark I was talking about "RomanSparse"...)
>>Yes, I agree that a Python implementation would be simpler and more
>>flexible than one in C. Perhaps our goal should be to build on the
>>existing TravisSparse module but replace the sparsetools Fortran code
>>with code from PySparse, which is probably better tested and debugged.
> Let's not through the baby out with the bath water :-) I spent a bit of
> time checking that code, and I don't know that PySparse code has the
> same functionality.
It does not - it is tied to 'double' (IMHO). On the other hand it does
have some hand-tailored optimizations in its routines. But I agree with
you that we should see first where the real bottlenecks are - the
premature optimization is evil :-)
> If speed is the issue, then we first need to understand what is actually
> "slowing" us down. We are basing things off a few comments.
> My suspicion is that speed improvements will be seen by using
> linked-lists for sparse matrix construction and perhaps a faster
> back-end for matrix factorization (I'm not sure how umfpack compares to
Yes, this is the point where I see great application for the LL matrix
> We could do this, but I'm really not sure of the improvement. The
> problem is that the different sparse matrices need such different
> structures underneath that there is not much benefit to having the base
> class in C.
More information about the Scipy-dev