![](https://secure.gravatar.com/avatar/8dc4d0010b050a4bae0b632defb5c4f3.jpg?s=120&d=mm&r=g)
What were your conclusions after experimenting with chained ufuncs? If the speed is comparable to numexpr, wouldn’t it be `nicer` to have non-string input format? It would feel a bit less like a black-box. Regards, DG
On 15 Feb 2024, at 22:52, Marten van Kerkwijk <mhvk@astro.utoronto.ca> wrote:
Hi Oyibo,
I'm proposing the introduction of a `pipe` method for NumPy arrays to enhance their usability and expressiveness.
I think it is an interesting idea, but agree with Robert that it is unlikely to fly on its own. Part of the logic of even frowning on methods like .mean() and .sum() is that ndarray is really a data container, and should have methods related to that, as much as possible independent of the meaning of those data (which is given by the dtype).
A bit more generally, your example is nice, but a pipe can have just one input, while of course many operations require two or more.
- Optimization: While NumPy may not currently optimize chained expressions, the introduction of pipe lays the groundwork for potential future optimizations with lazy evaluation.
Optimization might indeed be made possible, though I would think that for that one may be better off with something like dask.
That said, I've been playing with the ability to chain ufuncs to optimize their execution, by applying the ufuncs in series on small pieces of larger arrays, thus avoiding large temporaries (a bit like numexpr but with the idea of defining a fast function rather than giving an expression as a string); see https://github.com/mhvk/chain_ufunc
All the best,
Marten
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: dom.grigonis@gmail.com