Hello Numpy community,
I'm proposing the introduction of a `pipe` method for NumPy arrays to enhance
their usability and expressiveness.
Similar to other data processing libraries like pandas, a `pipe` method would
allow users to chain operations together in a more readable and intuitive
On Thu, Feb 15, 2024 at 10:21 AM wrote:
> Hello Numpy community,
>
> I'm proposing the introduction of a `pipe` method for NumPy arrays to
> enhance their usability and expressiveness.
>
Adding a prominent method like this to `np.ndarray` is something that we
will probably not take up ourselves
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()
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 wrote:
>
> Hi Oyibo,
>
> From my experience, calling methods is generally faster than
> functions. I figure it is due to having less overhead figuring out the
> input. Maybe it is not significant for large data, but it does make a
> difference even when working for medium sized arrays - say float size
> 5000.
>
>
Thanks for this, every little helps.
One more thing to mention on this topic.
From a certain size dot product becomes faster than sum (due to parallelisation
I guess?).
E.g.
def dotsum(arr):
a = arr.reshape(1000, 100)
return a.dot(np.ones(100)).sum()
a = np.ones(10)
In [45]:
> 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.
I haven't gotten further than it yet, it is just some toying around I've
been
Just to clarify, I am not the one who suggested pipes. :)
Read the issue. My 2 cents:
From my experience, calling methods is generally faster than functions. I
figure it is due to having less overhead figuring out the input. Maybe it is
not significant for large data, but it does make a
Hi all,
in PyTorch they (kind of) recently introduced torch.compile:
https://pytorch.org/tutorials/intermediate/torch_compile_tutorial.html
In TensorFlow, eager execution needs to be activated manually, otherwise it
creates a graph object which then acts like this kind of pipe.
Don‘t know
> One more thing to mention on this topic.
>
> From a certain size dot product becomes faster than sum (due to
> parallelisation I guess?).
>
> E.g.
> def dotsum(arr):
> a = arr.reshape(1000, 100)
> return a.dot(np.ones(100)).sum()
>
> a = np.ones(10)
>
> In [45]: %timeit
> On 16 Feb 2024, at 2:48 am, Marten van Kerkwijk
> wrote:
>
>> In [45]: %timeit np.add.reduce(a, axis=None)
>> 42.8 µs ± 2.44 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)
>>
>> In [43]: %timeit dotsum(a)
>> 26.1 µs ± 718 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops
11 matches
Mail list logo