A protocol for numpy.ones_like

I recently sat down with @ericmjl to see if we could make autograd work with cupy by making them both understand protocols like __array_ufunc__

• https://github.com/HIPS/autograd/pull/397
• https://github.com/cupy/cupy/issues/1230

The goal here being to improve all projects to produce and consume numpy protocols rather than explicitly import each other in pair-wise plugin mechanisms.

One issue that we ran into is that autograd needs to produce new arrays, like ones (the gradient of sum) and random (not sure why yet). It would be nice to be able to say “produce an array of ones with a particular shape and dtype, but using the module that created this particular array object”. This would allow autograd to produce dask arrays of ones, cupy arrays of ones, etc…

The numpy.ones_like function almost does this except for the following two issues:

1. It takes the shape from the given array (which makes perfect sense given its original objective)
2. There is no protocol for it, so np.ones_like(my_duck_array, ...) produces a numpy array

Also, to be clear, ones here is an example of a larger problem of how to improve dispatch for a wider set of numpy functions.

[hameerabbasi]

There’s a related discussion over on #8994 about making the three-argument version of np.where dispatch to a ufunc.

Overall, I agree with @mrocklin fairly strongly here that Numpy should move towards a protocol-oriented and ufunc-based architecture where at all possible. This would allow for other projects and the ecosystem as a whole to benefit from this as well.

I would be willing to co-author an (or multiple) NEPs, perhaps in conjunction with @njsmith, @shoyer. Hopefully @mrocklin joins in too.

[mrocklin]

Conversation seems to have slowed down a bit here.

To summarize what I’m hearing above it sounds like at one point this was considered but then an alternative was put in place. It’s not clear what the reasoning was at the time, but presumably one could do some sleuthing to find out why. There is some mild concern from @shoyer that some code might be built expecting np.ones_like to definitely return a numpy array, which seems like a fair concern that should be discussed, but may not be a blocking issue. No one else has yet voiced strong dissent or support of this issue. Are there any other thoughts or concerns about this topic?

From my limited perspective the world would be a nicer place if Numpy would tend towards the default of making operations ufuncs. This would allow the ecosystem to evolve more quickly towards using generic code in gpu, sparse, and parallel situations.