[SciPy-dev] the current state and future directions of the sparse solvers
Ondrej Certik
ondrej@certik...
Tue Apr 8 11:39:18 CDT 2008
On Mon, Apr 7, 2008 at 8:07 PM, Robert Kern <robert.kern@gmail.com> wrote:
> On Mon, Apr 7, 2008 at 10:55 AM, Ondrej Certik <ondrej@certik.cz> wrote:
> > Hi,
> >
> > these are probably mainly questions to Nathan. :)
> >
> > First let me say that the new sparse functionality of scipy is
> > awesome, I really like it, it's just so easy and natural to work with
> > it. Thanks for your work on it.
> >
> > Here I have some points:
> >
> > 1) Why do you want to remove umfpack wrappers from scipy? I suggest to
> > leave wrappers in there (those can be BSD, cannot they?),
>
> That just confuses the issue. If you are going to use the UMFPACK
> functionality, you will need UMFPACK and the GPL. Consequently, the
> wrappers must be optional; all of scipy must be buildable and usable
> without any GPLed code.
Absolutely, scipy needs to just compile and just work, with BSD stuff
only by default.
> However, having optional functionality is bad;
> in order to depend on it you can't just tell your users "install
> scipy" but "install scipy with the UMFPACK wrappers installed". This
> makes it especially difficult for things like Linux distributions.
> They have to make the choice whether to include the GPL code or not.
> If they do, then they can't include a non-GPL-compatible package that
> depends on scipy. If they don't, they can't include a package that
> needs the UMFPACK wrappers.
nonrelated: Is there any package depending on scipy, incompatible with GPL?
>
> I would have spoken against the initial inclusion of the UMFPACK
> wrappers if I had been paying attention at the time. I am glad to see
> them being removed. However, just moving the wrappers to a scikit
> doesn't solve any problem if scipy code is requiring the scikit.
OK, I see your point. Honestly, I don't like this option either (to
have to decide at compile time which stuff is going in).
In this case, scipy should be pure BSD and that's it. It should not
depend on scikits, however when installing scicits, the umfpack
functionality will be back in. BTW, I don't like the current code in
scipy/sparse/linalg/dsolve/linsolve.py, that switches between superlu
and umfpack semiautomatically. I think there should be an easy to use
solver for superlu (in scipy) and a separate one for umfpack (in
scikits) ideally with the same interface.
On Mon, Apr 7, 2008 at 8:09 PM, Nils Wagner
<nwagner@iam.uni-stuttgart.de> wrote:
[...]
> > I have some improvements, for example
> > scipy/sparse/linalg/eigen/info.py is missing the lobpcg,
> >the attached
> > patch fixes that.
>
> lobpcg is currently disabled. See ticket
> http://projects.scipy.org/scipy/scipy/ticket/630
Right - I think Robert just fixed that now. Robert - could you please
commit the doc fix, if lobpcg is in now?
> BTW, a svd for sparse matrices would be nice, too.
Yep.
So 1) and 5) were answered.
Nathan, do you have any comments to 2), 3) and 4)?
For example, here is a code that converts a scipy matrix for petsc4py solvers:
from petsc4py.PETSc import Mat
def convert_csr2petsc(mtx):
assert isspmatrix_csr(mtx)
A = Mat().createSeqAIJ(mtx.shape, nz=mtx.shape[0])
i = mtx.indptr
j = mtx.indices
v = mtx.data
A.setValuesCSR(i, j, v)
A.assemble()
return A
I understand that scipy wants to be BSDed and self-contained, but I
think all similar code (either external or non BSD) should go to
scikits then.
I mean - I am using all these different solvers and I would like to
have them all under one roof, using the same interfaces ideally. So I
wanted to check,
if this is fits well with the scipy and scipy.sparse intentions, or I
should rather think how to do it in some separate project (scikit),
but even in this case I'd like to put as many things into scipy as
possible and only reuse scipy + add more things.
Ondrej
More information about the Scipy-dev
mailing list