[SciPy-User] Sparse matrices and dot product

David david@silveregg.co...
Sun Nov 28 22:52:23 CST 2010


On 11/29/2010 11:32 AM, Nathaniel Smith wrote:
> On Sun, Nov 28, 2010 at 7:16 AM, Pauli Virtanen<pav@iki.fi>  wrote:
>> However, I believe 'dot' should be left to be there. `ndarrays` recently
>> gained the same method for matrix products, so it makes sense to leave it
>> be also for sparse matrices. This has also the advantage that it becomes
>> possible to write generic code that works both on sparse matrices and on
>> ndarrays.
>
> If it's been decided that ndarray's should have a dot method, then I
> agree that sparse matrices should too -- for compatibility. But it
> doesn't actually solve the problem of writing generic code. If A is
> dense and B is sparse, then A.dot(B) still won't work.
>
> I just spent a few minutes trying to work out if this is fixable by
> defining a protocol -- you need like an  __rdot__ or something? -- but
> didn't come up with anything I'd want to actually recommend.
>
> (In fact, there are lots of other problems with writing generic code,
> like the behavior of __mul__ and the way sparse matrices like to turn
> all dense results into np.matrix's instead of np.ndarray's. The API
> seems designed on the assumption that everyone will use np.matrix
> instead of np.ndarray for everything, which I guess is fine, but since
> I personally never touch np.matrix my generic code ends up pretty
> ugly. I don't see how to do better without serious API breakage *and*
> a lot more cooperation from numpy. The only full solution might be to
> add sparse matrix support to numpy, and eventually deprecate
> scipy.sparse?)

Agreed. I think good sparse support will require a significant overhaul 
- for example being based on representation for sparse tensor instead of 
just sparse matrices.

This would take a lot of time, though, so it should not prevent 
temporary fixes in the meantime,

cheers,

David


More information about the SciPy-User mailing list