[Numpy-discussion] Generalized ufuncs?

[Robert Kern]

On Sun, Aug 17, 2008 at 19:13, Engel, Hans-Andreas
<Hans-Andreas.Engel at deshaw.com> wrote:
> I am sorry that our submission
> http://projects.scipy.org/scipy/numpy/ticket/887 has created some
> annoyance; presumably we have taken the "Make contributions (e.g. code
> patches), (...) by submitting a 'ticket' on the Trac pages linked below"
> on http://scipy.org/Developer_Zone somewhat too literally.

Not at all. You did everything right. Unfortunately, it comes at a
slightly awkward time. We are just about to make a release, and this
is a substantial feature that some of us developers think needs a
little more consideration than we can give it if we were to put it
into this release. It's only the timing that triggered the conflict,
not anything you really had control over.

> It was great to receive very positive responses to our patch and to
> receive a very timely review; this is encouraging for submitting code to
> the numpy repository.
>
> I would like to add that the proposed change is not that arbitrary; it
> is a well-established concept -- it is outlined on the
> GeneralLoopingFunctions wiki page, and it is a prominent concept of
> perl's PDL vector library.  Of course, there is still room for arguing
> about details.
>
> The fact that no explicit "generalized" ufuncs are provided, should in
> my opinion not be an argument why not to include the change in the 1.2.0
> release.  Writing extension libraries that implement such generalized
> ufuncs, while being able to use the standard numpy distribution, would
> certainly be very valuable.
>
> Furthermore, the risk for including the proposed patch in 1.2.0 is very
> low: existing functionality is not touched.  (Except the glitch we had
> by declaring variables in a gcc-way.)  For standard ufuncs, it should be
> straightforward to see that the patch does not modify the behavior at
> all.

My concern is not that the patch might be buggy or anything like that.
Rather, this is a substantial feature, and one that affects the C API.
It will be very difficult to remove it or modify it later if we find
that it needs even a slight tweak to its design. Despite its use in
other array languages, it's new to us, and I think we need to explore
its use cases a little. numpy isn't PDL, and the way this feature
integrates with the rest of numpy's semantics and idioms is important
to figure out. It's possible that there are problems that it could
solve with just a slight modification to the design.

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. If you have
examples that you have already written, I would love to see them. I,
for one, am amenable to seeing this in 1.2.0, but only if we push back
the release by at least a few weeks.

-- 
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