[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day

[Nathan Bell]

On Jan 22, 2008 7:43 AM, Matthieu Brucher <matthieu.brucher at gmail.com> wrote:
> > Yes, arpack should go into the sparse package.  If you have the time,
> > it would be great if you could help get it moved over.  Ideally, we
> > can get it moved into scipy.sparse before the 0.7 release around the
> > end of March.
>
> I have some time to do this (besides I need the package), so if the
> whereabouts of arpack are solved (ie where it should be put with which
> interface), , I can help moving arpack from the sandbox to the trunk and
> apply the long awaited patch (if I'm given commits privileges).

AFAIK the current proposal is as follows

scipy.sparse
    Will contain the sparse matrix classes and perhaps construction
functions (e.g. spdiags)

scipy.splinalg
    New home for sparse linear algebra (i.e. anything that has a dense
analog in scipy.linalg)
    Possible home for sparse construction functions (e.g. spkron)

splinalg.eigen
    Sparse eigensolvers:
        sandbox.lobpcg -> splinalg.eigen.lobpcg
        sandbox.arpack -> splinalg.eigen.arpack

        a function splinalg.eigen.eigs() should support a simplified
interface to ARPACK,
        without exposing many ARPACK-specific parameters (allowing the
backend to be
        changed in the future)

splinalg.isolve
    Iterative solvers for linear systems (e.g. cg, gmres):
        linalg.iterative -> splinalg.isolve

splinalg.dsolve
    Direct solvers for linear systems (e.g. SuperLU):
        scipy.linsolve -> splinalg.dsolve
        scipy.linsolve.umfpack -> scikit


-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/