[SciPy-dev] Sparse matrix module

[Robert Cimrman]

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
>>>necessary.
>>>   
>>>
> 
> 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 
> SuperLU).  

Yes, this is the point where I see great application for the LL matrix 
of PySparse.

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

+1

r.