I don't think the CI failures are related to the patch, right?

I reran the problematic CI checks and they passed.
Thanks @r-devulap

@pllim and I are confused: we thought that with the disabling done in this PR, cos(0) would actually produce exactly 1 again, but with 1.25.0 we still seem unable to revert the changes we made to accommodate that no longer being the case with vectorized operations. Are we mistaken? Is this just for large vectors being (even) less precise?

EDIT: See astropy/astropy#14946

I don't have the architecture to check AVX512, but 1.25.0 works fine with what I have. The problematic code should have been disabled in the 1.25.0 release, it is in the changelog. Maybe we haven't got it quite right yet?

I don't have AVX512 either, and cannot reproduce the failures we see... Will try to find something more up to date.

I don't think it is cos(0) but cos(90 deg). I can reproduce this on WSL2 using numpy 1.25.0 and it matches one of the failure reported over at astropy/astropy#14946 . Is this expected?

>>> import numpy as np
>>> np.__version__
'1.25.0'
>>> np.cos(0)  # OK
1.0
>>> # [0, 45, 90] deg
>>> res = np.cos([0, 0.78539816, 1.57079633])
>>> np.testing.assert_allclose(res, [1, 0.707107, 0])  # Traceback

Particularly...

For 45 deg:

Not equal to tolerance rtol=1e-07, atol=0

Mismatched elements: 1 / 1 (100%)
Max absolute difference: 2.16411094e-07
Max relative difference: 3.06051409e-07
 x: array(0.707107)
 y: array(0.707107)

For 90 deg:

Not equal to tolerance rtol=1e-07, atol=0

Mismatched elements: 1 / 1 (100%)
Max absolute difference: 3.20510345e-09
Max relative difference: inf
 x: array(-3.205103e-09)
 y: array(0)

np.cos(1.57079633) is not 0, since the input cannot possibly be exactly 90 degrees? Or am I misreading things?

Not enough digits in the input.

In [1]: pi/2
Out[1]: 1.5707963267948966

In [2]: pi/4
Out[2]: 0.7853981633974483

The point is our tests that used to pass with numpy 1.24 or older is still not passing after this reversion in numpy 1.25. Sure, I can try exact pi divided by something, but I still get disagreement in numpy 1.25. Is no one else seeing this?

>>> res = np.cos([0, np.pi / 4, np.pi / 2])
>>> res
array([1.00000000e+00, 7.07106781e-01, 6.12323400e-17])
>>> np.testing.assert_allclose(res[1], 0.707107)  # traceback, see below
>>> np.testing.assert_allclose(res[2], 0)  # traceback, see below

AssertionError:
Not equal to tolerance rtol=1e-07, atol=0

Mismatched elements: 1 / 1 (100%)
Max absolute difference: 2.18813452e-07
Max relative difference: 3.09448856e-07
 x: array(0.707107)
 y: array(0.707107)

AssertionError:
Not equal to tolerance rtol=1e-07, atol=0

Mismatched elements: 1 / 1 (100%)
Max absolute difference: 6.123234e-17
Max relative difference: inf
 x: array(6.123234e-17)
 y: array(0)

But I'll wait for @mhvk to comment since he knows the original design of tests that are failing better than I do.

@pllim I am not sure what is going on. But the values you are posted are the same I have on NumPy 1.23 on linux: I.e. those values seem like the correctly rounded results. Exactness can only be expected for x = 0 and when the result would be 1.0 (since than we know it should round correctly).

Yeah I noticed a similar thing (see below) but I got distracted from posting until now:

>>> import numpy as np
>>> np.__version__
'1.23.5'
>>> np.cos(np.pi / 2)
6.123233995736766e-17
>>> np.cos(np.pi / 4)
0.7071067811865476
>>> np.cos(0)
1.0

Just a little surprising we couldn't do a clean revert, but it also could be caused by our own changes. 🤷

This is the actual test case and if you look at the blame, we have not touched it for 6 years but yet only now it fails:

            testcase(
                f=np.cos,
                q_in=(np.array([0.0, np.pi / 4.0, np.pi / 2.0]) * u.radian,),
                q_out=(np.array([1.0, 1.0 / np.sqrt(2.0), 0.0]) * u.one,),
            ),

https://github.com/astropy/astropy/blob/f3f3b5def16a5a28ae655f51e08356e5f661ffb6/astropy/units/tests/test_quantity_ufuncs.py#L154-L158

Ah, could be I missed something in the reversion... hang on.

Okay, I think disagreement with numpy 1.25 is addressed (my bad!), however... did you un-revert this in 2.0.dev? Or are the failures here (only appear when we pull in numpy "nightly" wheel) something else? Thanks!

https://github.com/astropy/astropy/actions/runs/5324760647/jobs/9644536347?pr=14946