On Saturday, 20 October 2012 04:31:34 UTC+8, jason wrote: > > On 10/19/12 8:05 AM, Dima Pasechnik wrote: > > > > > > On Friday, 19 October 2012 20:35:07 UTC+8, jason wrote: > > > > On 10/19/12 7:25 AM, Dima Pasechnik wrote: > > > While some ARPACK functionality is available in Sage from scipy > > (more is > > > implemented in scipy 0.11, than in currently available in Sage > scipy > > > 0.9, but this is taken care of in #13541, which I'm reviewing > > presently), > > > the functionality allowing to implement matrices as callback > > functions > > > (sometimes a big win in memory/speed) seems to be missing. > > > > > > Any idea how can this be handled? > > > > > > > Do you mean a sparse matrix class where A[i,j] actually calls some > > function that you supply? > > > > > > right. > > > > I'd make a subclass of sparse matrices (or > > maybe even dense matrices??), and just override the unsafe indexing > > method. I think all indexing ends up going through that function. > > > > > > well, it does not look that obvious (it's sparse scipy/numpy matrices: > > http://docs.scipy.org/doc/scipy/reference/sparse.html) and they have > > several member functions, such as __getitem__, _get_row_slice, etc... > > Oh, you're talking Scipy matrices, not Sage matrices. You're right; > that is different. I'd suggest posting to the scipy-dev mailing list. > It seems like it would make a nice addition to the sparse matrix classes > already there. > > Do the various fortran libraries support matrices with callable > functions? If Scipy is just handing off the matrix to a fortran > library, then it's just handing off a C (or Fortran) array, not a python > callable object, of course. > ARPACK has a "reverse communication interface", see: http://www.caam.rice.edu/software/ARPACK/UG/node9.html#exampint It only needs a routine for matrix-vector products. I just found out that scipy has a class scipy.sparse.linalg.LinearOperator that does just that, and instances of which can be passed to scipy.sparse.linalg.eigsh() instead of a matrix (sparse or dense).
OK, good, so I was reinventing the wheel here :-) Sorry for noise. Dima > > > > Hmm, I actually thought they are way more optimized, than what I saw in > > sage/scipy/sparse/csr.py > > > > I think most of the optimization is just in storage (various ways of > compressing) and in using sparse fortran packages. I'm sure they would > appreciate pull requests if you had some ideas for making them better, > though! > > Thanks, > > Jason > > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
