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/
On Fri, Jan 25, 2008 at 02:30:18PM -0600, Nathan Bell wrote:
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
I can look at those ARPACK tickets this weekend and help get the code moved. Aric
On Jan 25, 2008 3:08 PM, Aric Hagberg <hagberg@lanl.gov> wrote:
I can look at those ARPACK tickets this weekend and help get the code moved. Aric
Excellent. I know a lot of people (myself included) look forward to mainline ARPACK support. I've taken care of item (4). For now, UMFPACK support is retained, but this should be removed by 0.7 Let me know if I've broken anything in the process. -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/
Was it done ? If it was not, I could do it today. Matthieu 2008/1/25, Aric Hagberg <hagberg@lanl.gov>:
On Fri, Jan 25, 2008 at 02:30:18PM -0600, Nathan Bell wrote:
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
I can look at those ARPACK tickets this weekend and help get the code moved. Aric _______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.org http://projects.scipy.org/mailman/listinfo/scipy-dev
-- French PhD student Website : http://matthieu-brucher.developpez.com/ Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn : http://www.linkedin.com/in/matthieubrucher
On Mon, Jan 28, 2008 at 09:23:01AM +0100, Matthieu Brucher wrote:
Was it done ? If it was not, I could do it today.
2008/1/25, Aric Hagberg <[1]hagberg@lanl.gov>:
I can look at those ARPACK tickets this weekend and help get the code moved. Aric
I'm working on it. The tickets are fairly easily addressed except for adding more eigensolver modes (shifted etc) and a high-level interface. None of the complex matrix methods work for me on an Intel Mac (with OSX 10.5.1 fink, gfortran) and the tests result in a bus error. I'd like to track that down before I check it into the trunk. It appears at this point to be a LAPACK problem. Are there any known issues with this setup? Aric
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?
Yes. There are decorators in numpy specifically for this purpose. deprecate_with_doc deprecate Thanks so much for tackling this one. I look forward to the improved organization. -Travis O.
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
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.
On Jan 28, 2008 4:34 AM, Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
I will try to make a scikit of umfpack asap, keep it functional untill it is done, please.
Will do. I've added LinearOperator and aslinearoperator() to SVN: http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/splinalg/interface... aslinearoperator() accepts all of the things that made sense for the 'A' parameter of the iterative solvers (dense matrices, sparse matrices, and objects with .shape and .matvec() attributes) Take a look at it and let me know if you see any issues. I included a dtype attribute in LinearOperator to take the place of the xtype parameter of the iterative solvers. Next on the TODO list: Update iterative solvers to use aslinearoperator()/LinearOperator Replace A.psolve with precond=M parameter (where M is also a LinearOperator) Clean up MINRES translation: http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/splinalg/isolve/mi... And possibly: Generalize the stopping criteria used by the iterative solvers -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/
Nathan Bell wrote:
I've added LinearOperator and aslinearoperator() to SVN: http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/splinalg/interface...
aslinearoperator() accepts all of the things that made sense for the 'A' parameter of the iterative solvers (dense matrices, sparse matrices, and objects with .shape and .matvec() attributes)
Great! what about allowing the LinearOperator.__init__() to take care of the cases that aslinearoperator() takes care of? Or LinearOperator.fromany()/fromAny() static/class method? cheers, r.
On Jan 31, 2008 9:21 AM, Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Great! what about allowing the LinearOperator.__init__() to take care of the cases that aslinearoperator() takes care of? Or LinearOperator.fromany()/fromAny() static/class method?
I considered that approach but decided against it. I like keeping LinearOperator dead simple since it's what end users will have to understand if they want to hook up their matrix-like objects to scipy solvers. Currently aslinearoperator() is the part that "knows" about scipy/numpy while LinearOperator is just an abstract interface. Another practical issue is that LinearOperator needs to be initialized with at least two arguments (shape and matvec) while aslinearoperator() only accepts one. The classmethod approach avoids this, but I have a (possibly irrational) dislike for classmethods :) Scipy users should understand asarray(), so I think aslinearoperator() is a fairly natural extension. -- Nathan Bell wnbell@gmail.com http://graphics.cs.uiuc.edu/~wnbell/
Nathan Bell wrote:
On Jan 31, 2008 9:21 AM, Robert Cimrman <cimrman3@ntc.zcu.cz> wrote:
Great! what about allowing the LinearOperator.__init__() to take care of the cases that aslinearoperator() takes care of? Or LinearOperator.fromany()/fromAny() static/class method?
I considered that approach but decided against it. I like keeping LinearOperator dead simple since it's what end users will have to understand if they want to hook up their matrix-like objects to scipy solvers. Currently aslinearoperator() is the part that "knows" about scipy/numpy while LinearOperator is just an abstract interface.
Another practical issue is that LinearOperator needs to be initialized with at least two arguments (shape and matvec) while aslinearoperator() only accepts one. The classmethod approach avoids this, but I have a (possibly irrational) dislike for classmethods :)
Scipy users should understand asarray(), so I think aslinearoperator() is a fairly natural extension.
Ok, I have nothing against :) r.
participants (6)
-
Aric Hagberg -
Matthieu Brucher -
Nathan Bell -
Nils Wagner -
Robert Cimrman -
Travis E. Oliphant