[Numpy-discussion] GSoC proposal -- Numpy SciPy

Nathaniel Smith njs@pobox....
Tue Apr 30 18:53:08 CDT 2013


On Tue, Apr 30, 2013 at 4:02 PM, Pauli Virtanen <pav@iki.fi> wrote:
> 30.04.2013 22:37, Nathaniel Smith kirjoitti:
> [clip]
>> How do you plan to go about this? The obvious option of just calling
>> scipy.sparse.issparse() on ufunc entry raises some problems, since
>> numpy can't depend on or even import scipy, and we might be reluctant
>> to add such a special case for what's a rather more general problem.
>> OTOH it might be possible to solve the problem in general, e.g., see
>> the prototyped _ufunc_override_ special method in:
>>
>>   https://github.com/njsmith/numpyNEP/blob/master/numpyNEP.py
>>
>> but I don't know if you want to get into such a debate within the
>> scope of your GSoC. What were you thinking?
>
> To me it seems that the right thing to do here is the general solution.
>
> Do you see immediate problems in e.g. just enabling something like your
> _ufunc_override_?

Just that we might want to think a bit about the design space before
implementing something. E.g., apparently doing Python attribute lookup
is very expensive -- we recently had a patch to skip
__array_interface__ checks whenever possible -- is adding another such
per-operation overhead ok? I guess we could use similar checks (skip
checking for known types like int/float/ndarray), or only check for
_ufunc_override_ on the class (not the instance) and cache the result
per-class?

> The easy thing is that there are no backward compatibility problems
> here, since if the magic is missing, the old logic is used. Currently,
> the numpy dot() and ufuncs also most of the time do nothing sensible
> with sparse matrix inputs even though they in some cases return values.
> Which then makes writing generic sparse/dense code more painful than
> just __mul__ being matrix multiplication.

I agree, but, if the main target is 'dot' then the current
_ufunc_override_ design alone won't do it, since 'dot' is not a
ufunc...

-n


More information about the NumPy-Discussion mailing list