(original) (raw)

On Sat, Jun 30, 2018 at 11:59 AM Hameer Abbasi <einstein.edison@gmail.com> wrote:

Hi Marten,

Still, I'm not sure whether this should be included in the present NEP or is best done separately after, with a few concrete examples of where it would be useful.

There already are concrete examples from Dask and CuPy, and this is currently a blocker for them, which is part of the reason I’m pushing so hard for it. See #11074 for a context, and I think it was part of the reason that inspired Matt and Stephan to write this protocol in the first place.

Overloading np.ones_like() is definitely in scope already.

I’d love to see a generic way of doing random number generation, but I agree with Martin that I don’t see it fitting a naturally into this NEP. An invasive change to add an array_reference argument to a bunch of functions might indeed be worthy of its own NEP, but again I’m not convinced that’s actually the right approach. I’d rather add a few new functions like random_like, which is a small enough change that concensus on the list might be enough.