Can we have short-circuit equivalents to `allclose`, `array_equal`, `isfinite` and the like in numpy?

I did some (admittedly very dirty) benchmark of scipy.linalg.cho_solve(), and what surprised me was the magnitude of overhead due to check_finite=True, which is on by default. My notes can be read here.

The finiteness-check is useful, if not plain necessary for some scenarios, but can we do better? In many user cases such as the scipy.linalg functions, all that matters is that some element of an array is NaN or infinity. Now, what it has to do, is to call numpy.asarray_chkfinite, which in turn does something amounting to numpy.isfinite(a).all(). But this does not short-circuit; isfinite() checks each single element and returns a Boolean array. This whole test can be expensive, but can it be made less expensive in the best case?

This issue is also present in the test of closeness and equality, in core/numeric.py. Neither allclose() nor array_equal() actually short-circuits when doing the real check. They only short-circuit in the all() function/method call, which is already too late. These two functions can be especially deceiving. Spoiled by Python’s built-in all(), the user may think these functions do the short-circuit evaluation. The docs never mention they don’t.

So the request is… Do you think it’s worthwhile to add some short-circuit Boolean functions for the above tests (finiteness/equality/closeness)?

[seberg]

I am going to close this. There are two possibilities:

1. Specialized gufuncs for performance optimiation to replace some chained operation: gh-18483
2. A chaining operation map_reduce like addition to the ufunc machinery (or addition build on top of it): gh-11622 (and other issues like it)

Both probably make sense for certain functions.

[jakirkham]

So it looks like PR ( https://github.com/numpy/numpy/pull/6980 ) went in, but was then reverted. Unclear as to whether it was readded later or not. Does anyone know?