[Numpy-discussion] Generalized ufuncs?
Travis E. Oliphant
Mon Aug 18 11:13:51 CDT 2008
> 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).
More information about the Numpy-discussion