[SciPy-dev] the current state and future directions of the sparse solvers
Nathan Bell
wnbell at gmail.com
Tue Apr 8 16:22:32 EDT 2008
On Mon, Apr 7, 2008 at 12:55 PM, Ondrej Certik <ondrej at certik.cz> wrote:
Sorry for the late reply, I'm a little busy at the moment.
Your concerns/goals are quite reasonable and
> 1) Why do you want to remove umfpack wrappers from scipy? I suggest to
> leave wrappers in there (those can be BSD, cannot they?), otherwise
> it will be much harder for scipy users to use umfpack (they would have
> to install scikits too). If so, could this warning message be removed?
I have to agree with Robert K. on this point. Self-containment is a
big deal IMO.
> 2) why was pysparse removed? are there any objections of adding it
> among arpack and lobpcg solvers?
If I'm not mistaken, pysparse lived in the sandbox and the core
functionality has largely been replaced/superceeded by that in
scipy.sparse.
I have no opposition to reintroducing pysparse solvers that are
missing in scipy.sparse, provided that someone is willing to maintain
them.
> 3) sometimes I also use blzpack - are there any objections if I
> implement it (if I find time of course) the same way lobpcg and arpack
> is in there?
I'm not familiar with blzpack, but I don't see any reason to prohibit
it (assuming it's compatible with the BSD).
> 4) I would love to see all available open source sparse solvers and
> eigensolvers to be callable from scipy. Is this the intention of
> scipy.sparse?
Supporting a common interface to the various solvers would be quite
useful. However, like (2) we should not support interfaces to
optional libraries/methods.
> Those are enough questions so far, depending on the answers, I'll
> probably have some more then, regarding the interface. :)
This is a valuable idea, however given the scope of the solvers you'd
like to include, a scikit is more appropriate. It would be very
confusing to users that something under the scipy namespace required
UMFPACK/PETSc/etc. A scikit could support all these solvers while
remaining self-contained. I doubt it would require much time before
such a scikit became a commonly-installed component. Furthermore,
living outside SciPy would permit us to add functionality on a
separate timetable. As you've suggested, any functionality with an
appropriate license (and sufficient appeal) could be moved to SciPy
itself.
We should start a wiki page (like
http://projects.scipy.org/scipy/scipy/wiki/ArpackWrapper ) to discuss
the interface.
> I have some improvements, for example
> scipy/sparse/linalg/eigen/info.py is missing the lobpcg, the attached
> patch fixes that.
Added in r4118
--
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/
More information about the SciPy-Dev
mailing list