python – 为什么不是“numpy.any”懒惰(短路)

发布时间：2020-12-20 12:13:14 所属栏目：Python 来源：网络整理

导读：我不明白为什么还没有进行如此基本的优化： In [1]: %timeit np.ones(10**6).any()100 loops,best of 3: 7.32 ms per loopIn [2]: %timeit np.ones(10**7).any()10 loops,best of 3: 59.7 ms per loop 即使结论是第一项的证据,也扫描整个阵列. 解决方法这是

我不明白为什么还没有进行如此基本的优化：

In [1]: %timeit np.ones(10**6).any()
100 loops,best of 3: 7.32 ms per loop

In [2]: %timeit np.ones(10**7).any()
10 loops,best of 3: 59.7 ms per loop

即使结论是第一项的证据,也扫描整个阵列.

解决方法

这是一个不确定的性能回归. NumPy issue 3446.实际上有 short-circuiting logic,但是对ufunc.reduce机器的改变在短路逻辑周围引入了一个不必要的基于块的外环,而外环不知道如何短路.您可以看到有关分块机械 here的一些解释.

尽管如此,即使没有回归,短路效应也不会出现在你的测试中.首先,你正在为数组创建计时,其次,我不认为他们曾经为任何输入dtype输入短路逻辑而是布尔.从讨论中,它听起来像numpy背后的ufunc减少机制的细节.任何人都会这么难.

讨论确实提出了一个令人惊讶的观点,即argmin和argmax方法似乎是布尔输入的短路. A quick test显示,从NumPy 1.12开始(不是最新版本,但目前在Ideone上的版本),x [x.argmax()]短路,并且它超过x.any()和x.max()无论输入是小还是大,无论短路是否得到回报,一维布尔输入.奇怪的！

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!