[Numpy-discussion] Generalized ufuncs?

[Engel, Hans-Andreas]

"Charles R Harris" <charlesr.harris at gmail.com> wrote in message news:<e06186140808171929n705f347dj7b158162b580baef at mail.gmail.com>...
On Sun, Aug 17, 2008 at 7:56 PM, Stéfan van der Walt <stefan at sun.ac.za>wrote:

> 2008/8/17 Robert Kern <robert.kern at gmail.com>:
> > I suggested that we move it to a branch for the time being so we can
> > play with it and come up with examples of its use.
>
> That branch is here:
>
> http://stefan@svn.scipy.org/svn/numpy/branches/gen_ufuncs
>
>
For an earlier thread about using vector valued ufuncs for sorts and such --
and negative reactions to the suggestion -- go
here<http://thread.gmane.org/gmane.comp.python.numeric.general/20552/focus=20560>.
One of the major objections was how to call such functions with the ufunc
machinery and the needed machinery for type promotions, sub classes, and all
that nonsense. Are these dealt with in the patch? The current numpy code for
all that is a bit of a mess anyway, and it would be nice to figure out some
unified interface to call through and clean up the current code in the
process. In fact, I've been making some preliminary efforts in that
direction by formatting the current code and working through it. Also, do we
also want reduce methods and such? I suspect there is still a lot of work to
do to get this whole thing up and running.

Chuck

----------


The good news is that the patch just uses of the existing code to deal with all the tricky issues (this is why the patch is so short).  By the way, sort could be implemented with the proposed specifications, its signature would be "(i)->(i)".  I agree that it would be nice if that code could be made somewhat clearer; however, I think that this task is orthogonal to the generalized ufuncs patch, because there is no code overlap.  

The way the suggested implementation basically works is to remove the "core dimensions" from the input/output arrays, and then have the existing code handle all the intricacies over the "loop" dimensions.

Reduce methods are currently not supported (an error is raised).  Therefore, the current patch does not forestall anything and the desired functionality can be added whenever it is clear what would be best.

I do not think that it would makes sense to specify/implement all possible extensions, optimizations, concrete ufuncs, morphing of existing numpy functions to ufuncs, etc. at once; presumably it is much better to start with a small but extremely flexible specification of generalized ufuncs first.

Best,
Hansres