Repository navigation
test_trace sporadically fails under numpy #455
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.
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.