On Fri, 25 Jan 2008 14:30:18 -0600 "Nathan Bell" <wnbell@gmail.com> wrote:
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
There is another ticket with respect to ARPACK http://projects.scipy.org/scipy/scipy/ticket/418 Cheers, Nils
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/ _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev