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

[Robert Kern]

On Sat, Apr 19, 2008 at 12:18 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> On Fri, Apr 18, 2008 at 11:02 PM, Robert Kern <robert.kern at gmail.com> wrote:
> > On Fri, Apr 18, 2008 at 11:58 PM, Charles R Harris
> >
> > <charlesr.harris at gmail.com> wrote:
> > >
> > > On Fri, Apr 18, 2008 at 10:53 PM, Robert Kern <robert.kern at gmail.com>
> wrote:
> > > >
> > > > On Fri, Apr 18, 2008 at 11:47 PM, Charles R Harris
> > > > <charlesr.harris at gmail.com> 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.
> > > >
> > > > axis?
> > >
> > > I believe Travis is already selecting an axis to get the best cache
> usage,
> > > so it just needs a tweak. Axis = None is the special case.
> >
> > So what is the benefit here? Why bother?
>
> Code reuse and a unified concept. Why duplicate all the complication as we
> do now? Argsorts become binary ufuncs, etc. Besides, I'm trying to track
> down a ufunc call bug, feeling annoyed, and it would be nice to have all the
> crap in one location so we can work on cleaning it up.

I have a suspicion that tweaking ufuncs to allow the special case of
sorting will negate the benefits. It smells like an abuse of the
machinery rather than a natural merging of similar functionality.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco