[Numpy-discussion] Sparse matrix hooks

[Ed Schofield]

Pearu Peterson wrote:
> On Mon, 27 Feb 2006, Ed Schofield wrote:
>> Yes, we've defined __rmul__, and this works fine for dense arrays, whose
>> __mul__ raises an exception.  The problem is that matrix.__mul__ calls
>> dot(), which doesn't raise an exception, but rather creates an oddball
>> object array:
>>
>> matrix([[  (1, 0)       0.0
>>  (2, 1)        0.0
>>  (3, 0)        0.0,
>>          (1, 0)        0.0
>>  (2, 1)        0.0
>>  (3, 0)        0.0,
>>          (1, 0)        0.0
>>  (2, 1)        0.0
>>  (3, 0)        0.0]], dtype=object)
>>
>>
>> We could potentially modify the __mul__ function of numpy's matrix
>> objects to make a guess about whether an array constructed out of the
>> argument will somehow be sane or whether, like here, it should raise an
>> exception.  But this would be difficult to get right, since the sparse
>> matrix formats are quite varied (some supporting the map/sequence
>> protocols, some not, etc.).  But being able to test isinstance(arg,
>> spmatrix) would make this easy.
>
> Sure, isinstance(arg,spmatrix) would work but it is not a general
> solution for performing binary operations with matrices and such user
> defined objects that numpy is not aware of. But these objects may be
> aware of numpy matrices or arrays. Sparse matrix is one example. Other
> example is defining a symbolic matrix. Etc.
> So, IMHO matrix.__mul__ (or dot) should be fixed instead.

Ah, yes, this could be the simplest solution (at least to the __mul__
problem).  We could redefine matrix.__mul__ as

def __mul__(self, other):
    if isinstance(other, N.ndarray) or not hasattr(other, '__rmul__') \
            or N.isscalar(other):
        return N.dot(self, other)
    else:
        return NotImplemented

This seems to fix multiplication.  I may make a case later for sparse
matrix hooks for other functions, but I don't see a pressing need right
now. ;)


-- Ed