[SciPy-dev] scipy.splinalg or bust

[Robert Cimrman]

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.