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

Charles R Harris charlesr.harris@gmail....
Sat Apr 19 00:41:47 CDT 2008


On Fri, Apr 18, 2008 at 11:29 PM, Charles R Harris <
charlesr.harris@gmail.com> wrote:

>
>
> On Fri, Apr 18, 2008 at 11:23 PM, Robert Kern <robert.kern@gmail.com>
> wrote:
>
> > On Sat, Apr 19, 2008 at 12:18 AM, Charles R Harris
> > <charlesr.harris@gmail.com> wrote:
> > > On Fri, Apr 18, 2008 at 11:02 PM, Robert Kern <robert.kern@gmail.com>
> > wrote:
> > > > On Fri, Apr 18, 2008 at 11:58 PM, Charles R Harris
> > > >
> > > > <charlesr.harris@gmail.com> wrote:
> > > > >
> > > > > On Fri, Apr 18, 2008 at 10:53 PM, Robert Kern <
> > robert.kern@gmail.com>
> > > wrote:
> > > > > >
> > > > > > On Fri, Apr 18, 2008 at 11:47 PM, Charles R Harris
> > > > > > <charlesr.harris@gmail.com> wrote:
> > > > > > > The signature for a ufunc is something like
> > > > > > >
> > > > > > > @TYPE@_@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.
>
>
> Don't think so, the ufunc inner loops are all over a given axis with the
> other indices varying. I think anything that processes arrays along an axis
> is a natural for the framework. And if we add bells and whistles, like
> threads, it might be nice to keep everything in one place.
>

You can also do matrix multiplication in a ufunc. It's got two inputs and an
output. Needs two axis specs, but other than that goes in quite nicely.
IIRC, BLAS already has the strides built in.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080418/d3ee20d8/attachment-0001.html 


More information about the Numpy-discussion mailing list