Fix dpnp.tensor.acosh handling of complex(+-0, NaN)

[vlad-perevezentsev]

This PR proposes to fix issue #2880 where dpnp.tensor.acosh(complex(0, NaN)) returned NaN + NaN j instead of NaN ± π/2 j as required by the Array API specification

The issue was caused by an incorrect early-return branch in acosh.hpp:

if (std::isnan(ry)) {
    return resT{ry, ry};
}

This special case bypassed the general logic which already produces the correct result.

The fix removes this unnecessary branch making the behavior consistent with both the Array API specification and NumPy

In [1]: import dpnp.tensor as dpt

In [2]: import numpy as np

In [3]: a = dpt.asarray([complex(+0, np.nan)])

In [4]: dpt.acosh(a)
Out[4]: usm_ndarray([nan+1.57079633j])

In [5]: a = np.asarray([complex(+0, np.nan)])

In [6]: np.acosh(a)
Out[6]: array([nan+1.57079633j])

Also adds a new test_acosh_zero_nan test to cover this case

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/pull/2914/index.html

[coveralls]

coverage: 78.441% (-0.003%) from 78.444% — fix_acosh_nan into master

[github-actions]

Array API standard conformance tests for dpnp=0.21.0dev0=py313h509198e_23 ran successfully.
Passed: 1357
Failed: 3
Skipped: 16

[antonwolfy]

we need to place a comment that NumPy returns wrong result: NaN + NaN j
and probably to add a link to the issue in NumPy repo

[ndgrigorian]

conda-forge numpy gives the nan, nan result, while wheels give the 0, nan result, because of something to do with numpy dispatching

numpy/numpy#29167 (comment)

probably, it would be best to just not use numpy for testing these kinds of edge case results

[vlad-perevezentsev]

Yes, I have noticed that too
It is better not to compare it to NumPy at all
Thank you!

[antonwolfy]

But both cases seem invalid, we expect NaN ± π/2 j based on the spec. Should we report then?

[ndgrigorian]

But both cases seem invalid, we expect NaN ± π/2 j based on the spec. Should we report then?

PyPI isn't incorrect

In [1]: import numpy as np

In [2]: vals = [complex(np.nan, -np.inf), complex(-np.inf, np.nan), complex(0, np.nan)]

In [3]: x = np.array(vals)

In [4]: np.arcsinh(x[0]), np.arcsin(x[1]), np.arccosh(x[2])
Out[4]:
(np.complex128(inf+nanj),
 np.complex128(nan+infj),
 np.complex128(nan+1.5707963267948966j))

the last case is NaN + pi/2, it's only conda-forge which is incorrect.

I don't think we shouldn't file, just noting that, they are transiently aware of it and it's platform-dependent for NumPy failure

[antonwolfy]

I see, I thought the same faulty result for PyPI.

[antonwolfy]

I guess it might be simplified:

Suggested change

	pi_half = np.full(len(x), np.pi / 2, dtype=xf.real.dtype)
	assert np.all(np.isnan(Y_dpt.real))
	assert_allclose(abs(Y_dpt.imag), pi_half, atol=1e-6)
	assert np.isnan(Y_dpt.real).all()
	assert_allclose(np.abs(Y_dpt.imag), np.pi / 2, atol=1e-6)

[antonwolfy]

The only minor nit in the tests. The remaining is absolutely LGTM!
Thank you @vlad-perevezentsev