Re: [Numpy-discussion] Starting work on ufunc rewrite
![](https://secure.gravatar.com/avatar/6bb00051bfad145a01112a5acf354c77.jpg?s=120&d=mm&r=g)
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. Irwin On Thu, Mar 31, 2016 at 4:00 PM, Jaime Fernández del Río <jaime.frio at gmail.com <https://mail.scipy.org/mailman/listinfo/numpy-discussion>> wrote: pretty large and *>* complex codebase. I am not sure that working on this on my own and *>* eventually sending a humongous PR is the best approach. Any thoughts on how *>* best to handle turning this into a collaborative, incremental effort? Anyone *>* who would like to join in the fun? *>>* Jaime *>>* -- *>* (\__/) *>* ( O.o) *>* ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus planes de *>* dominación mundial. *>>* _______________________________________________ *>* NumPy-Discussion mailing list *>* NumPy-Discussion at scipy.org <https://mail.scipy.org/mailman/listinfo/numpy-discussion> *>* https://mail.scipy.org/mailman/listinfo/numpy-discussion <https://mail.scipy.org/mailman/listinfo/numpy-discussion> *>
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Thu, Mar 31, 2016 at 3:09 PM, Irwin Zaid <izaid@continuum.io> wrote:
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? -n -- Nathaniel J. Smith -- https://vorpus.org
![](https://secure.gravatar.com/avatar/97c543aca1ac7bbcfb5279d0300c8330.jpg?s=120&d=mm&r=g)
On Thu, Mar 31, 2016 at 3:09 PM, Irwin Zaid <izaid@continuum.io> wrote:
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? -n -- Nathaniel J. Smith -- https://vorpus.org
participants (2)
-
Irwin Zaid
-
Nathaniel Smith