BUG: ppc64le uses double-double for np.float128, routines need adjustment

EDIT: TL;DR: the initial problem description below results from np.float128 being a double-double and the manylinux2014 image using glibc2.17, which blacklists some glibc trig functions triggering use of our replacements which are 80-bit double specific

Original issue report:

On some systems, LDBL_EPSILON, which is defined as a number that fits (1.0L + LDBL_EPSILON) != 1.0L && (1.0L + LDBL_EPSILON/2) == 1.0L, is 0. This causes problems in complex math routines, especially when calculating the recipricol as const npy_longdouble RECIP_EPSILON = 1.0L / LDBL_EPSILON;

I discovered this when running -mfull tests on ppc64le. I got an overflow warning when calling np.arcsinh, and debugging led to the conclusion that LDBL_EPSILON is 0.

One possible mitigation is to add RECIP_EPSILON to the pre-calculated values on the line above it, but that presumes that the internal representation of longdouble, which wikipedia says may be problematic. On the other hand, all the values in these calculations seem to presume a X86 80-bit long double.

Thoughts?

[charris]

I am not quite remember the story behind the new getlimits.py definitions

We needed to fix it in order to support PPC. It used to be computed but didn’t work because the computation assumed the usual mantissa/exponent representation. The number used was recommended somewhere (IBM?). @matthew-brett was responsible for the actual work in #8504.

What is long double on those machines to begin with?

IBM DoubleDouble, or should be.

[Flamefire]

This is still an issue (numpy 1.22.3)