Skip to content

Re-enable dim=4 in strided matmul test with proper cross-BLAS tolerances #2949

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
antonwolfy wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Re-enable dim=4 in strided matmul test with proper cross-BLAS tolerances #2949

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d279e64
Rever changes in the tests done in gh-2912
antonwolfy Jun 15, 2026
8086796
Keep matvec test tolerance while re-enabling dim=4 in strided matmul …
antonwolfy Jul 15, 2026
0ded231
Widen float32 tolerance in test_strided1 instead of skipping dim=4
antonwolfy Jul 16, 2026
a2e65f9
Merge branch 'master' into revert-gh-2912
antonwolfy Jul 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 13 additions & 6 deletions dpnp/tests/test_product.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -887,9 +887,14 @@ def test_order(self, dtype, order1, order2, order, shape1, shape2):
ids=["-2", "2", "(-2, 2)", "(2, -2)"],
)
def test_strided1(self, dtype, stride):
# TODO: enable back when the root cause is identified
# for dim in [1, 2, 3, 4]:
for dim in [1, 2, 3]:
# dpnp copies the strided input into a c-contiguous array and runs the
# batched product through oneMKL gemm_batch, while NumPy uses OpenBLAS.
# The two backends accumulate in a different order, so the float32
# result deviates at the noise floor (~2e-5 for a length-20 contraction
# with dim=4), which exceeds the default tolerance. Integer input is
# exact, so the factor only affects the float32 case.
factor = 24 if dtype == numpy.float32 else 16
for dim in [1, 2, 3, 4]:
shape = tuple(20 for _ in range(dim))
A = generate_random_numpy_array(shape, dtype)
iA = dpnp.array(A)
Expand All @@ -900,7 +905,7 @@ def test_strided1(self, dtype, stride):
# the 2D base is not c-contiguous nor f-contigous
result = dpnp.matmul(ia, ia)
expected = numpy.matmul(a, a)
assert_dtype_allclose(result, expected, factor=16)
assert_dtype_allclose(result, expected, factor=factor)

OUT = numpy.empty(shape, dtype=result.dtype)
out = OUT[slices]
Expand All @@ -909,7 +914,7 @@ def test_strided1(self, dtype, stride):
result = dpnp.matmul(ia, ia, out=iout)
assert result is iout
expected = numpy.matmul(a, a, out=out)
assert_dtype_allclose(result, expected, factor=16)
assert_dtype_allclose(result, expected, factor=factor)

@pytest.mark.parametrize("dtype", _selected_dtypes)
@pytest.mark.parametrize(
Expand Down Expand Up @@ -1545,7 +1550,9 @@ def test_axes(self, axes):
result = dpnp.matvec(ia, ib, axes=axes)
expected = numpy.matvec(a, b, axes=axes)

# TODO: check if failing with newer NumPy
# dpnp uses oneMKL gemm_batch while NumPy uses OpenBLAS gemv, so the
# summation order differs and the float64 result deviates at the noise
# floor (~1e-14), which exceeds the default tolerance
assert_dtype_allclose(result, expected, factor=40)

@pytest.mark.parametrize("xp", [numpy, dpnp])
Expand Down
Loading