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

[Robert Cimrman]

Dag Sverre Seljebotn wrote:
> 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.

IANAL either, so yes, I am +0 on that.

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

+1 to have the same license for all the scikit parts.

Nathaniel, I have looked at the docs [1] (btw. very nice!) and noticed that you 
use capital letters to denote matrices in function and method names. What is 
general opinion on this considering the recommendations [2] (specifically [3])?

In this case, the issue could be side-stepped by replacing the specialized 
functions, e.g. all Factor.solve_*() by a single function, e.g. Factor.solve( 
..., mode='A') with a 'mode' argument. What do you think? Typing
Factor.solve_P(b) or Factor.solve(b, 'P')
seems of the same complexity/readability to me.

cheers,
r.

[1] http://packages.python.org/scikits.sparse/
[2] http://projects.scipy.org/numpy/wiki/CodingStyleGuidelines
[3] http://www.python.org/dev/peps/pep-0008/