Thanks @MilesCranmer.

I think the API would be nicer if both kind methods just worked with empty arrays. Perhaps there could be an early check for ar2.size == 0 that returns False for each value in ar1, regardless of which kind is chosen.

Completely agree. I was thinking it might be better to submit a quick fix now to get rid of the bug, then work on a smarter fix later.

I don't really see that the float error should not happen for empty arrays (i.e. I don't like a fast path), but of course passing kind="table" must still work if the integer array is empty.

Sooner is better, but I don't think we need to bother with multiple iterations of fixes. Instead of a hot fix, go straight for the smart fix.

Could I do something like this at the start of the method, for all kind?

if ar1.size == 0:
    return np.array([], dtype=bool)
if ar2.size == 0:
    return np.zeros_like(ar1, dtype=bool)

With the corresponding inverse if inverse is true.

The error is with np.min(ar2) for empty ar2 so I think there has to be some sort of check like this. I guess ar1 doesn’t need its own check, though.

It looks like you'll need to do something in that if block before calling np.min(ar2), so it seems like that fast check for ar2.size == 0 there would be reasonable. Whether that check should be done earlier, and whether the fast path for ar1.size == 0 should be included, is an implementation detail that @seberg might have a stronger opinion about.

Okay I just put in the one for ar2.size == 0. ar1 can actually already be empty with kind="table" so no need for the other fast path.

I put this fast path within the codeblock for kind="table". My reasoning is that kind="table" should still throw an error when passed a float type, rather than randomly work if given an empty array with dtype=np.float64. Having this check within the table method still allows the normal error checking to work.

What do you both think?

(Ready for review)

Looks good, lets just put it in to unbreak. The "interesting" case is always things like shapes. But that won't matter here.

Awesome, thanks