Nathan Bell 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)?
Our entire lab is now moving into a new building, my computer currently sits on a table in a room full of boxes and stuff, so I am not sure about a timeline. Moving-man career awaits me. I will try to make a scikit of umfpack asap, keep it functional untill it is done, please. (1) can wait a bit more imho. The problem with using scipy.linalg.eig is that the LOBPCG algorithm does not work correctly with it - originally I was using it but kept getting large numerical errors when comparing step by step with the reference matlab implementation by A. Knyazev, the author of the algorithm. Symeig solved those problems. thanks for tackling this! r.