[SciPy-dev] scipy.splinalg or bust

[Nathan Bell]

I've started migrating code to scipy.splinalg.

Completed tasks:

      (1) linalg.iterative -> splinalg.isolve
           http://projects.scipy.org/scipy/scipy/changeset/3861

           For backwards compatibility scipy.linalg imports all the
           iterative solvers from  splinalg.isolve .  This is needed to
           avoid breaking things like  'from scipy.linalg import cg'
           What's the best way to inform the user that these functions
           have moved?  Is there a nice way to decorate these functions
           to issue a warning?

Remaining tasks:

       (1) sandbox.lobpcg -> splinalg.eigen.lobpcg
       (2) sandbox.arpack -> splinalg.eigen.arpack
       (3) create splinalg.eigen.speigs
       (4) scipy.linsolve -> splinalg.dsolve
       (5) scipy.linsolve.umfpack -> scikit
       (6) create LinearOperator wrapper class and document it
       (7) document splinalg.dsolve
       (8) document splinalg.isolve
       (9) document splinalg.eigen

I will start working on (4) now.  Should I remove umfpack in the process?
linalg
Robert C, can you give us a timeline on (1) and (5)?  Can (1) be done
without symeig (perhaps using scipy.linalg.eig as a fallback)?

Any volunteers for (2) and (3)?  For reference:
   http://projects.scipy.org/scipy/scipy/wiki/ArpackWrapper
Here are the remaining ARPACK tickets:
    http://projects.scipy.org/scipy/scipy/ticket/231
    http://projects.scipy.org/scipy/scipy/ticket/366
    http://projects.scipy.org/scipy/scipy/ticket/554


We discussed a plan for (6) in this thread:
http://thread.gmane.org/gmane.comp.python.scientific.devel/7070/focus=7285
Any comments/suggestions are most welcome.



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