This has come up before I think, but in the wider context of also providing integer specializations. I don't remember if there were objections, or if the pr just stalled. I'll comment with links when I find the PR (s?) I'm thinking of

@eric-wieser Thanks, that would be appreciated if you're able to locate any prior discussions.

For additional context, here's a trivial example of how this manifests to a user (especially in a library like pandas):

import numpy as np

bools = np.full(10**6, 1, bool)
ints = np.full(10**6, 1, int)

%timeit np.isnan(bools)
6.33 ms ± 195 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit np.isnan(ints)
864 µs ± 28 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

So any user reliant on NaN-masking currently sees a ~7.3x speedup by using ints instead of bools for storing bool data, which encourages use of overly broad types for performance reasons.

I'm not sure I understand how a user would nan-mask bool or int data. Either way, it surprises me that the ints are faster than the bools.

Ok, this is the second time I've tried and failed to find that PR, so I think I'm going to give up.

You should be able to reuse your isnan, isfinite, and isinf loops for all the integer types.

If you want to extend this PR to that, one thing to watch out for is that these functions need to not return true on np.datetime64('nat') and np.timedelta64('nat').

If you want to avoid this pain, you could at least add loops for bBhHiI types, and stick a TODO in about adding it for lLqQ types.

@eric-wieser A common scenario would be using pandas, which adds a NaN-mask to most functions, including all() and any():

bools = pd.Series(np.full(10**6, 1, bool))
ints = pd.Series(np.full(10**6, 1, int))

%timeit bools.all()
7.63 ms ± 88.7 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit ints.all()
2.7 ms ± 20.3 µs per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit np.all(bools.to_numpy())
51.4 µs ± 695 ns per loop (mean ± std. dev. of 7 runs, 10000 loops each)

%timeit np.all(ints.to_numpy())
747 µs ± 46.9 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each)

So pretty painful overhead from NaN masking in the bool case.

My PR pandas-dev/pandas#25070 would try and fix the pandas side of things, but there's still some low-hanging fruit in the numpy case.

Needs a release note.

Thanks for adding the integer loops.

Can you check that the following passes?

@pytest.mark.parametrize('nat', [np.datetime64('nat'), np.timedelta64('nat')])
def test_nat_is_not_finite(self, nat):
    try:
        assert not np.isfinite(nat)
    except TypeError:
        pass  # ok, just not implemented

@pytest.mark.parametrize('nat', [np.datetime64('nat'), np.timedelta64('nat')])
def test_nat_is_nan(self, nat):
    try:
        assert np.isnan(nat)
    except TypeError:
        pass  # ok, just not implemented

@pytest.mark.parametrize('nat', [np.datetime64('nat'), np.timedelta64('nat')])
def test_nat_is_no_tinf(self, nat):
    try:
        assert not np.isinf(nat)
    except TypeError:
        pass  # ok, just not implemented

I'll build this branch locally and play around with it. Perhaps the failure mode I'm expecting doesn't exist, which would be great!

Needs a rebase - the new macros should move to fast_loop_macros.h

@eric-wieser Rebased and tests passing

@eric-wieser I've removed the benchmark from this PR.

@charris, look good to merge?

@charris Are there any desired changes to this approach? I have several more patches in this vein that I've held off on submitting until this is merged.

I'll go ahead and put this in - nothing here seems controversial

Looks OK aside from some style/organization nits. The depth of the macro nesting makes it a bit hard to follow, but looks correct. The original behavior of promoting to float looks weird in truth, but no weirder than the functions being called on integer/boolean types :)

@charris Thanks for the comments and please see #13208 for implementation

Thanks @eric-wieser for merging!