[SciPy-dev] sparse array indexing.
Nathan Bell
wnbell@gmail....
Mon Apr 14 18:45:25 CDT 2008
On Mon, Apr 14, 2008 at 1:45 PM, Viral Shah
<vshah@interactivesupercomputing.com> wrote:
> Nathan, and others,
>
> A few more questions about the sparse array manipulation. Also, is
> there a sparse document in the works other than the one at http://www.scipy.org/SciPy_Tutorial
> ? I would be more than happy to put all that I am finding out in a
> document. But if one is in the works, I can edit that instead.
There are small number of updates in this document:
http://projects.scipy.org/scipy/scipy/browser/trunk/scipy/sparse/info.py
I don't know of any other sparse documentation.
> 1. I notice that A[I, J] behaves differently than in Matlab. This is
> documented. My question is, if one wants Matlab like behaviour, is
> there a better way to do this than A[I, :], A[:, J] ?
Like dense arrays the CSR and CSC formats now support indexing of the
form A[ [[0,1]], [0,1] ]
This ought to be equivalent to A[ [0,1], :][ :, [0,1] ]. Furthermore,
it should always perform the "right" indexing first (i.e. row first
for CSR)
> 2. Do the sparse data structures support deletion ?
Not to my knowledge. IIRC some formats like lil_matrix might remove
explicit zeros. I don't believe CSR/CSC do however.
> 3. How do I get the rows and columns as vectors out of the coo format,
> so that I can do the equivalent of find() in MATLAB ?
A = coo_matrix(A)
I,J,V = A.row,A.col,A.data
> 4. I forwarded the SuperLU bug to the upstream author, Sherry Li.
> Perhaps she will fix it in the next release. In general, I believe
> that Sherry does not spend much time maintaining the sequential
> SuperLU, but Tim Davis does support UMFPACK more actively. But UMFPACK
> does not have single precision.. So the solution for the default
> sparse direct solver is not as obvious. I would vote in favour of
> UMFPACK being the default solver for double precision, if its possible
> to put it in the scipy tree.
Unfortunately, as Robert K. pointed out, this is not possible.
UMFPACK is great software, but I think the recent move from LGPL to
GPL suggests that a relicensing under the BSD is unlikely.
Are you sure the bug exists in the most recent version of SuperLU?
Are you sure it's a SuperLU bug instead of a wrapper bug?
--
Nathan Bell wnbell@gmail.com
http://graphics.cs.uiuc.edu/~wnbell/
More information about the Scipy-dev
mailing list