[SciPy-dev] [announce] scikits.sparse v0.1, wrapper for CHOLMOD (and hopefully more)

[Dag Sverre Seljebotn]

Robert Cimrman wrote:
> Quoting Nathaniel Smith <njs at pobox.com>:
>
>   
>> As mentioned previously[0], I've written a scipy.sparse-compatible
>> wrapper for the CHOLMOD sparse Cholesky routines. I considered making
>> it 'scikits.cholmod' (cf. scikits.umfpack), but creating a new scikit
>> every time someone needs a sparse linear algebra routine seems like it
>> will become very silly very quickly, so instead I hereby declare the
>> existence of 'scikits.sparse' as a home for all such routines. (Of
>> course, it currently only contains scikits.sparse.cholmod).
>>
>> Manual:
>>   http://packages.python.org/scikits.sparse/
>> Source:
>>   hg clone https://scikits-sparse.googlecode.com/hg/ scikits.sparse
>> Homepage:
>>   http://code.google.com/p/scikits-sparse
>> Bug tracker:
>>   http://code.google.com/p/scikits-sparse/issues/list
>> Mailing list:
>>   scikits-sparse-discuss at lists.vorpus.org
>>   http://lists.vorpus.org/cgi-bin/mailman/listinfo/scikits-sparse-discuss
>>
>> I would have sucked scikits.umfpack in, except that it uses SWIG,
>> which I don't understand and am not really inspired to learn, at least
>> for a v0.1 release. Also, there appear to still be some sort of
>> complicated entanglements with scipy.sparse (e.g. in at least part of
>> the test suite). Anyone feeling inspired? It's not a very complicated
>> interface; just rewrapping it might be as easy as anything else.
>>     
>
> It would be great to have all the suitesparse in one scikit, thanks
> for working in that direction.
>
> Concerning the test entanglement - all direct umfpack references
> should be removed from scipy, the tests should live in the scikit
> IMHO. It's just my lack of time it's not done yet. As for wrappers,
> they just translate the numpy array arguments to the C arrays that
> umfpack expects - I guess it's the same you do with cython, so it
> should be easy to adapt. The umfpack scikit also uses a simple reuse
> mechanisms for the partial solution objects (symbolic, numeric, the LU
> factors etc.) - it would be great if this could be preserved. I cannot
> assist you right now by code as I am out of town this week, but I will
> gladly help with the conversion later.
>
> As for the wrapper licence, the umfpack scikit has been BSD, but I
> guess GPL is ok too, especially if the underlying library is GPL. Do
> you have a strong opinion on this?
>   
I'm not sure if you have a choice -- I believe SuiteSparse is under GPL, 
and I'd say a wrapper is clearly "derivative work"?

IANAL, but just something to keep in mind. Keeping it GPL will at least 
be on the safe side.

(Some parts of SuiteSparse might be under LGPL though, which would be 
ok, but if the scikit is going for be for all of SuiteSparse it would be 
less confusing to stick with GPL for the whole.)

Dag Sverre