[Numpy-discussion] GSoC proposal -- Numpy SciPy
Tue Apr 30 18:53:08 CDT 2013
On Tue, Apr 30, 2013 at 4:02 PM, Pauli Virtanen <firstname.lastname@example.org> wrote:
> 30.04.2013 22:37, Nathaniel Smith kirjoitti:
>> 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:
>> 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
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
> 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
More information about the NumPy-Discussion