[SciPy-dev] the current state and future directions of the sparse solvers
Tue Apr 8 16:00:28 CDT 2008
On Tue, 8 Apr 2008 22:46:34 +0200
"Ondrej Certik" <email@example.com> wrote:
> Hi Nathan!
> On Tue, Apr 8, 2008 at 10:22 PM, Nathan Bell
>> On Mon, Apr 7, 2008 at 12:55 PM, Ondrej Certik
>> Sorry for the late reply, I'm a little busy at the
> 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
>> functionality has largely been replaced/superceeded by
>> I have no opposition to reintroducing pysparse solvers
>> missing in scipy.sparse, provided that someone is
>>willing to maintain
> OK, thanks, I am willing to maintain it. I'll try to
> with the scipy solvers and if I find that pyspare has
> 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
>> > scipy.sparse?
>> Supporting a common interface to the various solvers
>>would be quite
>> useful. However, like (2) we should not support
>> 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
>> > Those are enough questions so far, depending on the
>> > probably have some more then, regarding the
>> This is a valuable idea, however given the scope of the
>> like to include, a scikit is more appropriate. It
>>would be very
>> confusing to users that something under the scipy
>> UMFPACK/PETSc/etc. A scikit could support all these
>> remaining self-contained. I doubt it would require
>>much time before
>> such a scikit became a commonly-installed component.
>> 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
> 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
> :) Plus umfpack. Plus the eigensolvers, like primme,
AFAIK Jacobi-Davidson is part of pysparse.
And you probably know slepc
And polyeig ... How about that ?
For nonlinear eigenvalue problems, see
More information about the Scipy-dev