我不明白为什么这么基础的优化还没有做:
In [1]: one_million_ones = np.ones(10**6)
In [2]: %timeit one_million_ones.any()
100 loops, best of 3: 693µs per loop
In [3]: ten_millions_ones = np.ones(10**7)
In [4]: %timeit ten_millions_ones.any()
10 loops, best of 3: 7.03 ms per loop
扫描整个数组，即使结论是第一项的证据。
最佳答案
这是一个不固定的性能回归。 NumPy issue 3446.实际上是 short-circuiting logic ，但对 ufunc.reduce 机制的更改在短路逻辑周围引入了一个不必要的基于 block 的外部循环，并且该外部循环不知道如何短路。你可以看到分块机制的一些解释here .
不过，即使没有回归，短路效应也不会出现在您的测试中。首先，您正在为数组创建计时，其次，我认为他们从来没有为除 bool 值之外的任何输入 dtype 添加短路逻辑。从讨论中可以看出，numpy.any 背后的 ufunc 缩减机制的细节会让这变得困难。
讨论确实提出了一个令人惊讶的观点，即 argmin 和 argmax 方法似乎对 bool 输入短路。 A quick test表明从 NumPy 1.12(不是最新版本，而是当前 Ideone 上的版本)开始，x[x.argmax()] 短路，并且胜过 x.any () 和 x.max() 用于一维 bool 输入，无论输入是小还是大，也不管短路是否有效。奇怪!
关于python - 为什么 "numpy.any"没有短路机制？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/45771554/