[Numpy-discussion] ufunc overrides

[Travis Oliphant]

Hey Blake,

To be clear, my blog-post is just a pre-NEP and should not be perceived as
something that will transpire in NumPy anytime soon.    You should take it
as a "hey everyone, I think I know how to solve this problem, but I have no
time to do it, but wanted to get the word out to those who might have the
time"

I think the multi-method approach I outline is the *right* thing to do for
NumPy.   Another attribute on ufuncs would be a bit of a hack (though
easier to implement).   But, on the other-hand, the current ufunc
attributes are also a bit of a hack.

While my overall proposal is to make *all* functions in NumPy (and SciPy
and Scikits) multimethods, I think it's actually pretty straightforward and
a more contained problem to make all *ufuncs* multi-methods.   I think that
could fit in a summer of code project.

I don't think it would be that difficult to make all ufuncs multi-methods
that dispatch based on the Python type (they are already multi-methods
based on the array dtype).    You could basically take the code from
Guido's essay or from Peak Rules multi-method implementation or from the
links below and integrate it with a wrapped version of the current ufuncs
(or do a bit more glue and modify the ufunc_call function in 'C' directly
and get nice general multi-methods for ufuncs).

Of course, you would need to define a decorator that NumPy users could use
to register their multi-method implementation with the ufunc.   But, this
again would not be too difficult.      Look for examples and inspiration at
the following places:

http://alexgaynor.net/2010/jun/26/multimethods-python/
https://pypi.python.org/pypi/typed.py

I really think this would be a great addition to NumPy (it would simplify a
lot of cruft around masked arrays, character arrays, etc.) and be quite
useful.   I wish you the best.     I can't promise I will have time to
help, but I will try to chime in the best I can.

Best regards,

-Travis




On Wed, Jul 10, 2013 at 10:29 PM, Blake Griffith <blake.a.griffith at gmail.com
> wrote:

> Hello NumPy,
>
> Part of my GSoC is compatibility with SciPy's sparse matrices and NumPy's
> ufuncs. Currently there is no feasible way to do this without changing
> ufuncs a bit.
>
> I've been considering a mechanism to override ufuncs based on checking the
> ufuncs arguments for a __ufunc_override__ attribute. Then handing off the
> operation to a function specified by that attribute. I prototyped this in
> python and did a demo in a blog post here:
> http://cwl.cx/posts/week-6-ufunc-overrides.html
> This is similar to a previously discussed, but never implemented change:
> http://mail.scipy.org/pipermail/numpy-discussion/2011-June/056945.html
>
> However it seems like the ufunc machinery might be ripped out and replaced
> with a true multi-method implementation soon. See Travis' blog post:
>
> http://technicaldiscovery.blogspot.com/2013/07/thoughts-after-scipy-2013-and-specific.html
> So I'd like to make my changes as forward compatible as possible. However
> I'm not sure what I should even consider here, or how forward compatible my
> current implementation is. Thoughts?
>
> Until then, I'm writing up a nep, it is still pretty incomplete, it can be
> found here:
>
> https://github.com/cowlicks/numpy/blob/ufunc-override/doc/neps/ufunc-overrides.rst
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 

Travis Oliphant
Continuum Analytics, Inc.
http://www.continuum.io
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20130711/2eefc088/attachment.html>