为什么是"numpy.any"?有没有短路机制? [英] Why "numpy.any" has no short-circuit mechanism?

问题描述

我不明白为什么尚未进行如此基本的优化:

I don't understand why a so basic optimization has not yet be done:

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

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

The whole array is scanned, even if the conclusion is an evidence at first item.

推荐答案

这是未修复的性能下降. NumPy问题3446.实际上，是 此处中看到有关分块机制的一些解释.

It's an unfixed performance regression. NumPy issue 3446. There actually is short-circuiting logic, but a change to the ufunc.reduce machinery introduced an unnecessary chunk-based outer loop around the short-circuiting logic, and that outer loop doesn't know how to short circuit. You can see some explanation of the chunking machinery here.

即使没有回归，短路影响也不会出现在您的测试中.首先，您要安排数组的创建时间，其次，我认为它们没有为布尔值的任何输入dtype放入短路逻辑.从讨论中看来，numpy.any背后的ufunc减少机制的细节将使这一工作变得困难.

The short-circuiting effects wouldn't have showed up in your test even without the regression, though. First, you're timing the array creation, and second, I don't think they ever put in the short-circuit logic for any input dtype but boolean. From the discussion, it sounds like the details of the ufunc reduction machinery behind numpy.any would have made that difficult.

讨论确实提出了令人惊讶的观点，即argmin和argmax方法似乎会因布尔输入而短路. 快速测试显示，自NumPy 1.12起(不是最新版本，而是Ideone当前的版本)， x[x.argmax()]短路，并且对于一维布尔输入，它都胜过x.any()和x.max()，无论输入是小还是大，无论短路是否奏效.奇怪！

The discussion does bring up the surprising point that the argmin and argmax methods appear to short-circuit for boolean input. A quick test shows that as of NumPy 1.12 (not quite the most recent version, but the version currently on Ideone), x[x.argmax()] short-circuits, and it outcompetes x.any() and x.max() for 1-dimensional boolean input no matter whether the input is small or large and no matter whether the short-circuiting pays off. Weird!

这篇关于为什么是"numpy.any"?有没有短路机制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！