[SciPy-Dev] numpy/npy_math.h vs C/C++ stdlib math.h/<cmath>

[Matti Picus]

On 8/5/21 10:40 pm, Peter Bell wrote:
> I've had a look through the npy_math.h implementation, most of which 
> is in this file:
> https://github.com/numpy/numpy/blob/main/numpy/core/src/npymath/npy_math_internal.h.src 
> <https://github.com/numpy/numpy/blob/main/numpy/core/src/npymath/npy_math_internal.h.src>
>
> All re-implementations of standard <math.h> functions are guarded by 
> "#ifndef HAVE_ at KIND@". i.e. they are only compiled on older toolchains 
> without C99 math library functions. SciPy requires C99 and C++11 
> already, so AFAIK all of the <cmath> functions should be available and 
> in fact call the same underlying implementation as the npy_math functions.
>
> My suggestion would be: prefer the standard library functions but 
> don't go out of your way to avoid npy_math.
>
> Cheers,
> Peter


It is a little more complicated and not dependent only on C99. Platforms 
that use glibc<2.18 or MSVC have known buggy implementations of some 
functions. Including npy_config.h will blocklist the known bad ones. 
Then the alternate implementations will be used.


Today it is impossible to produce a wheel with glibc >= 2.18: even 
manylinux2014 uses glibc 2.17 with the buggy functions. The problem is 
worse on IBM platforms where even the NumPy alternatives are buggy (long 
double is defined differently on Power and S390X, which breaks the NumPy 
functions). This is the reason I am pushing the manylinux2_24 wheel 
standard which will use glibc 2.24, and we can finally not use the NumPy 
alternatives.

Matti