[Numpy-discussion] numpy1.2 : make sorts unary ufuncs

[Travis E. Oliphant]

Charles R Harris wrote:
>
>
> On Sat, Apr 19, 2008 at 12:20 AM, Travis E. Oliphant 
> <oliphant at enthought.com <mailto:oliphant at enthought.com>> wrote:
>
>     Charles R Harris wrote:
>     > The signature for a ufunc is something like
>     >
>     > @TYPE at _@kind@(char **args, intp *dimensions, intp *steps, void
>     *func)
>     >
>     > Which contains all the info necessary to do a sort. Means and other
>     > such functions could also be implemented that way.
>     I dont' think the ufunc is the right place for this.    Perhaps
>     sorting
>     can be viewed however as a "general function" which I'd like to add.
>     Maybe, in that case the ufunc could be a special case of the "general
>     function" concept.   But, that is the direction I would expect the
>     discussion to go.
>
>     The ufunc object is a very particular kind of thing.   The 1-d inner
>     loop signature is a key part of it, but there is more to it than that.
>     I don't see  how the sorting function can be pushed into this concept.
>
>
> Yes, but the inner loop is just something that uses the array values 
> along that axis to produce another set of values, i.e., it is a vector 
> valued function of vectors. So is a sort, so is argsort, so is the 
> inner product, so on and so forth. That's what we have here:
>
> typedef void (*PyUFuncGenericFunction) (char **, npy_intp *, npy_intp 
> *, void *);
>
>  No difference that I can see. It is the call function in 
> PyUFuncObject that matters.
Yes, you are right that the low-level 1-d loop signature is similar (or 
can be made similar) to other signatures.  I'm not sure what is gained 
by that, though.   Can you explain exactly what you want to do? 

In my mind, the call function is exactly what makes a ufunc a ufunc, so 
I'm not sure why discussing sort in the same breath is meaningful.   
Perhaps we are just running around each others definitions.

-Travis