Re: [Numpy-discussion] Generalized ufuncs?
"Charles R Harris"
2008/8/17 Robert Kern
: 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:
For an earlier thread about using vector valued ufuncs for sorts and such -- and negative reactions to the suggestion -- go herehttp://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
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
On Mon, Aug 18, 2008 at 10:13 AM, Travis E. Oliphant wrote: 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 I agree with this.
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). I think the plan is that 1.2.1 will come out before the end of the year and
it would be reasonable to put the patch in there. As gen_ufuncs are
currently unused there is no practical effect to waiting until after the 1.2
release.
Chuck
participants (3)
-
Charles R Harris
-
Engel, Hans-Andreas
-
Travis E. Oliphant