[SciPy-dev] [announce] scikits.sparse v0.1, wrapper for CHOLMOD (and hopefully more)
Mon Dec 21 10:42:08 CST 2009
Dag Sverre Seljebotn wrote:
> Robert Cimrman wrote:
>> Quoting Nathaniel Smith <email@example.com>:
>>> As mentioned previously, 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).
>>> hg clone https://scikits-sparse.googlecode.com/hg/ scikits.sparse
>>> Bug tracker:
>>> Mailing list:
>>> 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  (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  (specifically )?
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.
More information about the SciPy-Dev