On Sat, Jun 30, 2018 at 11:59 AM Hameer Abbasi <<a href="mailto:einstein.edison@gmail.com">einstein.edison@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Marten,</div><div><br><blockquote class="m_-8320108248193213669hm_quoted_text" style="padding-left:8px;margin:0;border-left:1px solid rgb(185,185,185);color:rgb(100,100,100)">
    <div>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.</div></blockquote><div><br></div></div><div><div>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 <a href="https://github.com/numpy/numpy/issues/11074" target="_blank">#11074</a> 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.</div></div></blockquote><div dir="auto"><br></div><div dir="auto">Overloading np.ones_like() is definitely in scope already.</div><div dir="auto"><br></div><div dir="auto">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.</div></div>