If CI fails, that might be interesting for gh-30816. Otherwise, this PR can be closed probably. If it fails, it might make sense to convert it to a proper test. But then without the npy file, etc.)

@seberg, thanks a lot for triggering the CI. The run reflects the issue quite well, as the added test only fails in *linux_aarch64 containers, while any other platform-architecture combination seems fine. I'd be happy to try to create a proper test in numpy/linalg/tests/test_regession.py.

Yeah, does indeed reproduce, nice:

      def test_norm():
          test_array_path = Path(__file__).parent / "test_array.npy"
          test_array = np.load(test_array_path)
          norm = np.linalg.norm(test_array)
          print(f"norm = {norm}")
  >       assert np.isclose(norm, 1.0)
  E       assert np.False_
  E        +  where np.False_ = <function isclose at 0xff0eb80413f0>(np.float64(nan), 1.0)
  E        +    where <function isclose at 0xff0eb80413f0> = np.isclose
  
  norm       = np.float64(nan)
  test_array = array([ 0.00367843-0.00350762j,  0.00259778-0.01135681j,
         -0.00356539-0.00070692j, ...,  0.00231578-0.00841487j,
         -0.00324557+0.0058289j , -0.00042056-0.00383656j], shape=(15625,))
  test_array_path = PosixPath('/tmp/tmp.mCkoin/venv/lib/python3.12/site-packages/numpy/tests/test_array.npy')

@seberg, sorry that I didn't get back to this. Frankly speaking, I still don't understand where exactly the problem lies. Our test vector is rather large (5**6) and complex-valued, so it could be related to either of these two factors. I'll try to find time later today to create an example using np.random!

@seberg, the test I just added seems more reasonable to me. It only fails on the linux-24.04-arm runner in our CI, and I'm "hopeful" it fails here as well. 🤞

One observation: The test below passes on all platforms, so the problem is not just array size.

def test_norm_linux_arm(self) -> None:
    a = np.arange(20000)
    norm = np.linalg.norm(a)
    assert_almost_equal(norm, 1632931.9244843002)

There is a linting failure

Interesting. So the test passes when using ints, but fails for complex:

      def test_norm_linux_arm(self):
          # gh-30816
          a = np.arange(20000) / 50000
          b = a + 1j * np.roll(np.flip(a), 12345)
          norm = np.linalg.norm(b)
  >       assert_almost_equal(norm, 46.18628948075393)
  E       AssertionError: 
  E       Arrays are not almost equal to 7 decimals
  E        ACTUAL: np.float64(1.5141196919662592)
  E        DESIRED: 46.18628948075393

I pushed an update to use the new scipy-openblas 0.31.159.0, which will report its version number in the meson build and in show_runtime. One test should fail since I did not update the release build as well, lets see if the new test passes now. For a follow-up, we should add testing for show_runtime and/or threadpoolctl that the version listed in requirements/ci_requirements.txt is the one used in the build.

In this comment, NumPy 2.4.3 successfully passes the test if the shared object from scipy-openblas64==0.3.31.126.1 is used to replace the shared object from the wheel. This is strange, since they are supposed to be the same shared object, just with some RPATH twiddling. In this PR, I see at the beginning of tests that show_config is correctly reporting the new version of scipy-openblas but the test is failing. I am at a loss to explain what is going on. Maybe because the tests run in a docker quay.io/pypa/manylinux_2_28_aarch64:2026.03.01-1? I do not have access to a machine that exhibits the failure.

Progress. I found a cfarm build machine with SVE. I can reproduce the problem using the test here. It reproduces with all the scipy-openblas wheels. I will respond on the issue.

I updated scipy-openblas but apparently pypi has not percolated the change out yet. Restarting the failing CI to get the newer version.

the new test is passing. The failure is because I did not update the numpy/numpy-release repo with the newer scipy-openblas version.

the updated scipy-openblas is now part of the requirements for numpy-release, and rerunning the failing check tests now passes. @denialhaag can you confirm this fixes the problem?

Yes, looks good to me! Thanks a lot for all the effort!