Repository navigation
TestAVXFloat32Transcendental test failure #15179
Description
This test is failing on 64-bit Linux on the conda-forge Azure CI when building NumPy 1.18.0, see conda-forge/numpy-feedstock#179. Failed on Python 3.6, 3.7 and 3.8, so it's consistent. Not sure what's different about that setup, could be glibc version, compiler, or some Azure - TravisCI delta.
=================================== FAILURES ===================================
_______________ TestAVXFloat32Transcendental.test_sincos_float32 _______________
self = <numpy.core.tests.test_umath.TestAVXFloat32Transcendental object at 0x7f6a5342e080>
def test_sincos_float32(self):
np.random.seed(42)
N = 1000000
M = np.int_(N/20)
index = np.random.randint(low=0, high=N, size=M)
x_f32 = np.float32(np.random.uniform(low=-100.,high=100.,size=N))
# test coverage for elements > 117435.992f for which glibc is used
x_f32[index] = np.float32(10E+10*np.random.rand(M))
x_f64 = np.float64(x_f32)
> assert_array_max_ulp(np.sin(x_f32), np.float32(np.sin(x_f64)), maxulp=2)
E AssertionError: Arrays are not almost equal up to 2 ULP
This functionality came in in gh-13368, new in 1.18.0. Likely the accuracy is just slightly over 2 ULP, conda-forge tests need to be re-run with larger tolerance. (related: PR for improving the test function to show actual difference in gh-15178)
Cc @r-devulap
Activity
rgommers commentedon Dec 26, 2019
Update:
This is too much I think, needs looking into before putting this on conda-forge.
mattip commentedon Dec 26, 2019
When I look at conda-forge/numpy-feedstock#179, it seems all the azure runs fail trying to patch numpy. Which one shows this failure?
rgommers commentedon Dec 26, 2019
py36 and py38 (py37 has an unrelated error). e.g. https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=106332&view=logs&j=d0d954b5-f111-5dc4-4d76-03b6c9d0cf7e&t=6d4b912b-175d-51da-0fd9-4d30fe1eb4e7
r-devulap commentedon Dec 26, 2019
It is likely that this is coming from sin/cos computation for large numbers (> 117435.992f) in the C standard library used in that setup. These tests pass for Skylake client and Skylake server CPU's (which verify the FMA and AVX512F implementation of sin and cos). One way to confirm would be to check is the test passes if you remove the following line:
x_f32[index] = np.float32(10E+10*np.random.rand(M))rgommers commentedon Dec 30, 2019
Thanks for the suggestion @r-devulap!
h-vetinari commentedon May 9, 2021
I tried exploratively removing the skip for that test (which hasn't changed in the conda-forge recipe since then) in conda-forge/numpy-feedstock#227, and the failure is still there.
try suggestion from numpy issue for fixing test failure
h-vetinari commentedon May 11, 2021
Tried this in conda-forge/numpy-feedstock#227 with the following diff (see conda-forge/numpy-feedstock@e6e9ff9):
and indeed, the tests pass.
@r-devulap @rgommers, what's the takeaway from this? Should the glibc-dependent part of the test be spun off into a separate test (with a certain skip-condition)?
r-devulap commentedon May 11, 2021
@h-vetinari I think so. But I am wondering what would the skip condition be though?
h-vetinari commentedon May 11, 2021
Can we say something about the glibc-version used in CI here? The conda-forge anvil-image is pretty old (CentOs6 based) and uses glibc 2.12.
r-devulap commentedon May 14, 2021
I should be able to use
os.confstr('CS_GNU_LIBC_VERSION')to check the GLIBC version, but I am not sure what the minimum version should be. Any idea?mattip commentedon May 14, 2021
FWIW, we are still shipping wheels to be used with glibc2.12, at least until we drop manylinux2010. Glibc version for the different wheels we build (the latest release adds the aliases to the file names to make this clear):
here is a nice summary of GLIBC version for various linux distributions.
TST: skip coverage of large elements in sincos_float32 for ancient glibc
Add 64-bit Windows wheels [wheel build]