I had some thoughts, I'll just post. I am sorry, I hadn't quite finished them through, so the likely answer to most is "no need to worry":

• Unless we change this a bit, I think we could just merge things into a singlenp.isfinite() call? You could still add the second step if an error occurs (trade-off to make the normal thing faster). Micro-optimizers might even be tempted to optimize the normal scalar case, but I don't want to worry about it.
• This means we give a warning no matter the usernp.errstate() settings. I am slightly torn on that. OTOH, passing inf/nan is strange here. OTOH, if atol/rtol is an array for some reason(?) it might be reasonable to want to honornp.errstate().
• Typically, if a value is alreadyNaN we don't give a warning for comparisons. But that is just a (partially historic from compiler bugs) numpy thing, IEEE actually wants it for<= and I guess it makes sense here.
  (another thing that could make some sense is making NaN before like 0 for rtol/atol?)

I was wondering if re-arranging/narrower scoping of theerrstate context helps. I suspect it might work, but only by replacing non-finite values inabs(y) with 0 or so, so not sure it is a good path. (something to explorer if we care about theerrstate honoring only!)

@seberg I will look into that, but interestingly at the start I did not use np.any, but it gave me errors without it

This means we give a warning no matter the user np.errstate() settings. I am slightly torn on that. OTOH, passing inf/nan is strange here. OTOH, if atol/rtol is an array for some reason(?) it might be reasonable to want to honor np.errstate().

Seems reasonable to check the errstate before doing the warning, and e.g. ignore it or turn it into an error depending on the setting.

I agree this is an extra check in the fast path in service ofmaybe generating a warning in an uncommon case. That said, in almost all cases rtol and atol are scalars so this won't matter. If rtol and atol are arrays then if we check the errstate we can still give an escape hatch to bypass the isnan calls.

Also on reflection this is a behavior change and needs a release note.

• This means we give a warning no matter the usernp.errstate() settings. I am slightly torn on that. OTOH, passing inf/nan is strange here. OTOH, if atol/rtol is an array for some reason(?) it might be reasonable to want to honornp.errstate().

There is an slight issue with this as the invalid errstate is always'ignore', so should I check the errstate before the with? I can do it, but I don't know

with errstate(invalid='ignore'):        # atol and rtol can be arrays        if not (np.all(np.isfinite(atol)) and np.all(np.isfinite(rtol))):            warnings.warn(f"One of rtol or atol is not valid, atol: {atol}, rtol: {rtol}", stacklevel=2)          result = (less_equal(abs(x - y), atol + rtol * abs(y))                  & isfinite(y)                  | (x == y))        if equal_nan:            result |= isnan(x) & isnan(y)```

@ngoldbaum Hey, I've implemented the suggested changes and have done the release note. Is there anything else that's required?

Is there anything else that's required?

Sorry, I dropped this.

I think the test failure will go away if you rebase on or merge withmain. I added this to the 2.3 milestone which should ensure another developer will look at this before the next release.

@ngoldbaum Thanks! The rebase worked

Thanks@Tontonio3 .