[Numpy-discussion] GSoC proposal -- Numpy SciPy
Blake Griffith
blake.a.griffith at gmail.com
Wed May 1 14:12:46 EDT 2013
Oh wow, I just assumed that `dot` was a ufunc... However, it would still be
useful to have ufuncs working well with the sparse package. I don't
understand everything that is going on in
https://github.com/numpy/numpy/blob/master/numpy/core/src/umath/ufunc_object.c
But I assumed that I would be able to add the ability to check for
something like _ufunc_override_. I'm not sure where this piece of logic
should be inserted, or what the performance implications to NumPy would
be... I'm trying to figure this out. But major optimizations to ufuncs is
out of the scope of this GSoC.
I will look into what can be done about the `dot` function.
On Tue, Apr 30, 2013 at 6:53 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Tue, Apr 30, 2013 at 4:02 PM, Pauli Virtanen <pav at 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 at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130501/e567347c/attachment.html>
More information about the NumPy-Discussion
mailing list