test_trace sporadically fails under numpy #455
Copy link
Copy link
Open
Description
Caught in https://github.com/data-apis/array-api-compat/actions/runs/31951617577/job/95175816104?pr=464 : the values are very different:
FAILED array_api_tests/test_linalg.py::test_trace - AssertionError: The input arrays have different values (array(2048, dtype=uint32) != np.uint32(0)) (x_idxes = [(slice(None, None, None), slice(None, None, None))], res_idx = ())
adding @reproduce_failure('6.165.9', b'AEEIAEEEQQQoQfAAABAQAAAAAAAAAUEC'), as suggested by hypothesis shows this:
(Pdb) p x
array([[4.294968e+09, 4.294968e+09, 4.294968e+09, 4.294968e+09],
[4.294968e+09, 4.294968e+09, 4.294968e+09, 4.294968e+09],
[4.294968e+09, 4.294968e+09, 4.294968e+09, 4.294968e+09],
[4.294968e+09, 4.294968e+09, 4.294968e+09, 4.294968e+09]],
dtype=float32)
(Pdb) kw
{'dtype': <class 'numpy.uint32'>}
(Pdb) p xp.linalg.trace(x)
array(1.7179871e+10, dtype=float32) # correct value
(Pdb) p xp.linalg.trace(x, **kw)
array(2048, dtype=uint32) # incorrect
(Pdb) p xp.sum(np.diag(x), **kw) # trace matches sum
np.uint32(2048)
So what happens is that the summation is forced to occur in int32 and it overflows. The behavior comes straight from numpy.
The test effectively casts a float32 array to int32, which is not a very reasonable thing to do, and the (wrong) results depend on the order of operations in fairly unpredictable manner:
(Pdb) p xp.linalg.trace(xp.astype(x, xp.int32))
array(-8589934592)
(Pdb) p xp.linalg.trace(xp.astype(x, xp.int32), dtype=xp.int32)
array(0, dtype=int32)
What to do about it at the test suite level? Not entirely sure. We can either limit the range of values of x or only draw flowing-point dtype for floating-point x, for example.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Activity
prady0t commentedon Aug 17, 2026
Also see. We encountered this failure twice yesterday when working on data-apis/array-api-strict#240
But I think both times the CI went green on a rerun. Could you please rerun it to check if it goes away? If so, it must be flaky.
ev-br commentedon Aug 17, 2026
Yes it is flaky. Requires a conspiracy of numerically large values of the floating-point array and a narrow-width integral
dtype. Can ignore in unrelated PRs.