The `atanhl` function is broken under Rosetta 2 with 80-bit long
doubles, which numpy uses to implement long double complex numbers. This
results in a test failure. Attempts were made to change the
implementation of things, but that just changed the breakage.
The following Swift program demonstrates the problem.
import Foundation
import Numerics
let x = Float80(1.00000000e-20)
let z = Complex(x)
print("X: \(x), Z: \(z)")
let x_atanh = Float80.atanh(x)
let z_atanh = Complex.atanh(z)
print("atanh:")
print("X: \(x_atanh), Z: \(z_atanh)")
let d = abs(x_atanh / z_atanh.real - 1)
print("d: \(d)")
On x86_64-darwin hardware, it prints the following:
X: 1e-20, Z: (1e-20, 0.0)
atanh:
X: 1e-20, Z: (1e-20, 0.0)
d: 0.0
On aarch64-darwin under Rosetta 2, it prints the following:
X: 1e-20, Z: (1e-20, 0.0)
atanh:
X: 1e-20, Z: (-1.0237493319595677839e-40, 0.0)
d: 9.7680161420558978584e+19
The latter is obviously incorrect. FB12656897 was submitted to Apple,
but even if this is fixed eventually, this derivation needs to build for
users (and Hydra) who aren’t on the latest version.
checkInputs used to be added to nativeBuildInputs. Now we have
nativeCheckInputs to do that instead. Doing this treewide change allows
to keep hashes identical to before the introduction of
nativeCheckInputs.
This appears to be needed in some Python distutils for the library to
get on RPATH correctly. I’m not sure why this worked before, but I
needed this value set for Python 3.8 numpy to work correctly.
numpy has added hypothesis as a dependency for running property-based
tests:
https://github.com/numpy/numpy/pull/15189
However, hypothesis is not an input of the derivations. And thus tests
have been failing with:
ERROR .. - ModuleNotFoundError: No module named 'hypothesis'
https://hydra.nixos.org/build/124613306/nixlog/1
This change adds hypothesis to checkInputs, so that tests are run
again.
When using netlib lapack/blas, the section name doesn’t match what
numpy expects. So we need to add extra sections for both so that the
right directory is found. The original “blas.implementation” section
may not actually be still required, but it is still a good idea so
that numpy know whether to apply any blas-implementation specific
quirks.
Fixes#86613
