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

[Ondrej Certik]

Hi Nathan!

On Tue, Apr 8, 2008 at 10:22 PM, Nathan Bell <wnbell at gmail.com> wrote:
> 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.

Thanks for the reply. I am quite busy too at the moment. :)

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

OK, thanks, I am willing to maintain it. I'll try to substitute it
with the scipy solvers and if I find that pyspare has some advantages,
I'll prepare a patch.

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

Yes, it's 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.

You mean support in scipy by default, right? I would like to have the
unified interface to all solvers (including petsc and others).

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

OK, that sounds very good. I am going to study how to start such a
scikit and we are going to move our additional solvers we have in
sfepy to it (pysparse, soon petsc4py) -- are you ok with that Robert?
:) Plus umfpack.  Plus the eigensolvers, like primme, blzpack and
others.

And then we'll see how it goes and if some part is useful (like
pysparse or blzpack) and with BSD license, it can later be moved to
scipy directly.

>
>  We should start a wiki page (like
>  http://projects.scipy.org/scipy/scipy/wiki/ArpackWrapper ) to discuss
>  the interface.

ok, I'll start it when we move things to the scikit.

Do you have some idea about the interface? I noticed the
linalg/interface.py, that's the way to go. This is only for the
iterative solvers though.

We need to devise some unified interface for the direct solvers and
also for eigensolvers. Ok, I'll try to follow the arpack example and
then we'll see if it's ok, or it needs some changes for example in the
blzpack case.

For example the lobpcg now in scipy has a different interface, doesn't it?

>  >  I have some improvements, for example
>  >  scipy/sparse/linalg/eigen/info.py is missing the lobpcg, the attached
>  >  patch fixes that.
>
>  Added in r4118

Thanks,
Ondrej