> 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
> 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
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]:
> 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.
>
>
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
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
> 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
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,
>
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()
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
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
11 matches
Mail list logo
