IntelPython / dpnp / 30472381019

78%

push

github

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

## Summary

gh-2912 introduced two temporary test workarounds after a CI failure on
`ubuntu-latest`:
- widened the tolerance on `TestMatvec::test_axes` to `factor=40`;
- disabled the `dim=4` iteration in `TestMatmul::test_strided1`.

Both failures share the same benign root cause, so this PR re-enables
the disabled coverage and replaces the ad-hoc mitigations with
documented, dtype-aware tolerances:

- **`test_axes`** (matvec, float64) — keeps `factor=40`. dpnp computes
`matvec` via oneMKL `gemm_batch` while NumPy uses OpenBLAS `gemv`; the
summation order differs and the float64 result deviates at the noise
floor (~1.4e-14), which exceeds the default `8e-15` tolerance.
- **`test_strided1`** (matmul) — re-enables `dim=4`. dpnp copies the
strided input to c-contiguous and runs it through oneMKL `gemm_batch`,
again against NumPy's OpenBLAS. For float32, the length-20 contraction
deviates by ~1.87e-5, just above the old `factor=16` bound (~1.81e-5),
so the tolerance is bumped to `factor=24` **for float32 only**
(pass-bound ~2.27e-5). Integer input is compared exactly and is
unaffected.

## Root cause

Neither discrepancy is a dpnp correctness bug. Both are expected
floating-point non-associativity between two different BLAS backends
(oneMKL vs OpenBLAS), surfaced when the conda-forge NumPy in CI advanced
its bundled OpenBLAS. There is nothing to fix upstream, so documented
tolerances are the correct handling and let us keep full test coverage
(including `dim=4`).

1546 of 2884 branches covered (53.61%)

Branch coverage included in aggregate %.

26470 of 32848 relevant lines covered (80.58%)

7918.81 hits per line