[SciPy-dev] the current state and future directions of the sparse solvers

[Nathan Bell]

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/