[SciPy-dev] sparse array indexing.

[Nathan Bell]

On Mon, Apr 14, 2008 at 1:45 PM, Viral Shah
<vshah at 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 at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/