[SciPy-dev] The future of the scipy.sandbox and a reminder of upcoming doc-day

Robert Cimrman cimrman3@ntc.zcu...
Wed Jan 2 04:03:10 CST 2008

Nathan Bell wrote:
> On Dec 27, 2007 9:11 PM, Jarrod Millman <millman@berkeley.edu> wrote:
>>> I'd like to see arpack in the sparse folder (?) very fast as some my code
>>> would need a sparse solver (I proposed that it could be moved in a scikit
>>> but it makes sense to keep it in scipy so that sparse solvers are available
>>> in scipy).
>> Yes, arpack should go into the sparse package.  If you have the time,
>> it would be great if you could help get it moved over.  Ideally, we
>> can get it moved into scipy.sparse before the 0.7 release around the
>> end of March.
> How do you see sparse being structured?  Currently sparse contains
> only the sparse matrix classes and a handful of creation functions
> (e.g. spdiags) and the iterative solvers live in
> scipy.linalg.iterative.

IMHO iterative solvers (eigen- or linear) do not care about the format 
of matrices they work with - all they need is the matrix action on a 
vector. Due to this I think they do not belong under scipy.sparse - they 
should work without change for dense matrices, or even for matrix-like 
objects that have only the matrix action (A*x) implemented. lobpcg.py 
works like that already - a user can pass in a dense/sparse matrix or a 

> It would be strange to put an eigensolver under sparse and iterative
> methods for linear systems under linalg.  Also, lobpcg should live
> along side arpack wherever they end up.  I could imagine a structure
> like:
> scipy.iterative.linear (for cg/gmres etc.)
> scipy.iterative.eigen (for arpack/lobpcg etc.)

+1. Maybe instead of 'iterative' I would use something like 
'isolve(r(s))' to indicate their purpose better.


More information about the Scipy-dev mailing list