Bug report

Three mtest cases added in gh-150534 fail bit-identically on NetBSD 10.1, OpenBSD 7.9 and DragonFly 6.4:

acospi10016: acospi[0.9999999998835847]: expected 4.857023409833964e-06, got 4.857023409975323e-06 (error = 1.41e-16 (166887 ulps); permitted error = 0 or 5 ulps)
acospi10022: acospi[0.9999999999999964]: expected 2.6831517105016303e-08, got 2.6831517105016326e-08 (error = 2.32e-23 (7 ulps); permitted error = 0 or 5 ulps)
acospi10104: acospi[0.9999996241289419]: expected 0.0002759844303031754, got 0.00027598443030317065 (error = 4.77e-18 (88 ulps); permitted error = 0 or 5 ulps)

These platforms have no acospi() in libm, so the fallback in Modules/mathmodule.c is used. It computes via acos(), and these libms (a shared old fdlibm lineage — hence the identical results) lose precision in acos(x) for x close to 1. The same fallback passes on FreeBSD and OpenIndiana, whose acos() is accurate.

Possible fixes: compute the fallback near 1 through the half-angle identity acospi(x) = 2*asinpi(sqrt((1-x)/2)), which avoids the inaccurate region of acos(); or relax the tolerance for these platforms.

Linked PRs

• gh-154146: Fix accuracy of the math.acospi() fallback near 1 #154148