[Numpy-discussion] ufunc overrides
travis at continuum.io
Thu Jul 11 01:01:15 EDT 2013
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
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:
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.
On Wed, Jul 10, 2013 at 10:29 PM, Blake Griffith <blake.a.griffith at gmail.com
> 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:
> This is similar to a previously discussed, but never implemented change:
> However it seems like the ufunc machinery might be ripped out and replaced
> with a true multi-method implementation soon. See Travis' blog post:
> 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:
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
Continuum Analytics, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion