[Numpy-discussion] Starting work on ufunc rewrite
njs at pobox.com
Sat Apr 2 21:15:41 EDT 2016
On Thu, Mar 31, 2016 at 3:09 PM, Irwin Zaid <izaid at continuum.io> wrote:
> Hey guys,
> I figured I'd just chime in here.
> Over in DyND-town, we've spent a lot of time figuring out how to structure
> DyND callables, which are actually more general than NumPy gufuncs. We've
> just recently got them to a place where we are very happy, and are able to
> represent a wide range of computations.
> Our callables use a two-fold approach to evaluation. The first pass is a
> resolution pass, where a callable can specialize what it is doing based on
> the input types. It is able to deduce the return type, multidispatch, or
> even perform some sort of recursive analysis in the form of computations
> that call themselves. The second pass is construction of a kernel object
> that is exactly specialized to the metadata (e.g., strides, contiguity, ...)
> of the array.
> The callable itself can store arbitrary data, as can each pass of the
> evaluation. Either (or both) of these passes can be done ahead of time,
> allowing one to have a callable exactly specialized for your array.
> If NumPy is looking to change it's ufunc design, we'd be happy to share our
> experiences with this.
Yeah, this all sounds very relevant :-). You can even see some of the
kernel of that design in numpy's current ufuncs, with their
first-stage "resolver" choosing which inner loop to use, but we
definitely need to make these semantics richer if we want to allow for
things like inner loops that depend on kwargs (e.g. sort(...,
kind="quicksort") versus sort(..., kind="mergesort")) or dtype
attributes. Is your design written up anywhere?
Nathaniel J. Smith -- https://vorpus.org
More information about the NumPy-Discussion