[Numpy-discussion] Generalized ufuncs?

[Travis E. Oliphant]

> 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.  
>   
I agree with this.     
> 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.
>   
One of the key reasons I'm enthused about the patch is because it's so 
small.   By enhancing the ufunc object and without changing the 
signature of the underlying function, the patch is able to implement the 
general description of a generalized ufunc.   

I think it is useful to evaluate whether or not a few more changes will 
allow more functionality with little cost, but I don't think it is worth 
holding up the patch hoping that the code will get "cleaned-up" (which 
all code needs according to somebody's definition of cleaning).

-Travis