[Numpy-discussion] Revised NEP-18, array_function protocol (original) (raw)

Hameer Abbasi einstein.edison at gmail.com
Thu Jun 28 08:46:02 EDT 2018

I think the usefulness of this feature is actually needed. Consider np.random.RandomState. If we were to add what I proposed, the two could work very nicely to (for example) do things like creating Dask random arrays, from RandomState objects.

For reproducibility, Dask could generate multiple RandomState objects with a seed sequential in the job numbers.

Looping in Matt Rocklin for this — He might have some input about the design.

Best Regards, Hameer Abbasi Sent from Astro <https://www.helloastro.com> for Mac

On 28. Jun 2018 at 14:37, Marten van Kerkwijk <m.h.vankerkwijk at gmail.com> wrote:

On Wed, Jun 27, 2018 at 3:50 PM, Stephan Hoyer <shoyer at gmail.com> wrote:

So perhaps it's worth "future proofing" the interface by passing obj and method to arrayfunction rather than only func. It is slower to call a func via func.call than func, but only very marginally (~100 ns in my tests).

That would make it more similar yet to __array_ufunc__, but I'm not sure how useful it is, as you cannot generically assume the methods have the same arguments and hence they need their own dispatcher. Once you're there you might as well pass them on directly (since any callable can be used as the function). Indeed, for __array_ufunc__, this might not have been a bad idea either...

-- Marten

NumPy-Discussion mailing list NumPy-Discussion at python.org https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180628/513f5f52/attachment.html>

More information about the NumPy-Discussion mailing list