[SciPy-dev] scipy.splinalg or bust
Mon Jan 28 04:34:26 CST 2008
Nathan Bell wrote:
> I've started migrating code to scipy.splinalg.
> Completed tasks:
> (1) linalg.iterative -> splinalg.isolve
> 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?
> 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
thanks for tackling this!
More information about the Scipy-dev