On Tue, Apr 30, 2013 at 4:02 PM, Pauli Virtanen <p...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion