Issue 1:
Describe the issue:

In numpy 1.19.3 or later, when using np.linalg.svd on a certain architecture, the 2nd and 3rd columns of the u result array and the 2nd and 3rd rows of the vh result arrays are switched.

Reproduce the code example:

import numpy as np
array = np.array([[-4.0, -2.0, -2.0], [-2.0, -4.0, -2.0], [-2.0, -2.0, -4.0]])
expected_u = np.array(
[
[-5.77350269e-01, 8.16496581e-01, -5.04179082e-17],
[-5.77350269e-01, -4.08248290e-01, -7.07106781e-01],
[-5.77350269e-01, -4.08248290e-01, 7.07106781e-01],
]
)
expected_vh = np.array(
[
[0.57735027, 0.57735027, 0.57735027],
[-0.81649658, 0.40824829, 0.40824829],
[-0.0, 0.70710678, -0.70710678],
]
)
(u, _, vh) = np.linalg.svd(array, full_matrices=False)
np.testing.assert_almost_equal(expected_u, u)
np.testing.assert_almost_equal(expected_vh, vh)

Error message:

Mismatched elements: 6 / 9 (66.7%)
Max absolute difference: 1.11535507
Max relative difference: 1.60871119e+16
x: array([[-5.7735027e-01, 8.1649658e-01, -5.0417908e-17],
[-5.7735027e-01, -4.0824829e-01, -7.0710678e-01],
[-5.7735027e-01, -4.0824829e-01, 7.0710678e-01]])
y: array([[-5.7735027e-01, -5.0754703e-17, 8.1649658e-01],
[-5.7735027e-01, -7.0710678e-01, -4.0824829e-01],
[-5.7735027e-01, 7.0710678e-01, -4.0824829e-01]])

Exited with code exit status 1

Runtime information:

1.19.3

3.9.13 (main, May 27 2022, 22:45:39)

[GCC 9.4.0]

Note: This behavior is also occurring with numpy 1.24.1

Context for the issue:

The behavior is observed in CircleCI with the following info:

Docker with Python using cimg/python:3.9.13

Model name: Intel(R) Xeon(R) Platinum 8124M CPU @ 3.00GHz

Branch featuring bug: https://github.com/lace/entente/tree/numpy-bug

Failure in CI: https://app.circleci.com/pipelines/github/lace/entente/1829/workflows/8973da1a-38f4-46a3-8dc5-63a8a1e4ee17/jobs/5937

CI config: https://github.com/lace/entente/blob/numpy-bug/.circleci/config.yml

Not reproducible on MacOS or Linux native.

Not reproducible on MacOS or Linux with same Docker image.

Not reproducible in Numpy 1.19.2.

Issue 2:
Describe the issue:

NPZ files are zip archives and may contain duplicate entries. While numpy.savez prevents this by ensuring unique keys on the API level, it is easy to generate a .npz file with duplicate keys by other means, e.g. using zipfile.ZipFile.

When iterating over such a .npz file via NpzFile.items(), duplicate keys are yielded multiple times, but always with the last value stored. It is not possible to retrieve previous values stored under that key (at least not using the NpzFile API) although they are contained in the zip archive.

I would expect one of these alternative behaviors for NpzFile.items():

Yield a duplicate key only once (with the last value stored). This is consistent with the dictionary-like API of NpzFile, but discards content in the zip archive.

Yield the correct values stored with duplicate keys. This is consistent with the content of the zip archive, but somewhat at odds with the dictionary-like API.

If there is any interest, I can start contributing a PR for either behavior.

Reproduce the code example:

from zipfile import ZipFile
import numpy as np

# Generate data.npz with duplicate keys

with ZipFile("data.npz", "w") as zf:
for a in ([1], [2, 2], [3, 3, 3]):
with zf.open("duplicate_key.npy", "w") as f:
np.save(f, a)

# Iterating over data.npz with NpzFile.items() yields the last value multiple times

for key, val in np.load("data.npz").items():
print(key, val)

# Output:
# duplicate_key [3 3 3]
# duplicate_key [3 3 3]
# duplicate_key [3 3 3]

# But all three original values are still contained in zip file

with ZipFile("data.npz", "r") as zf:
for info in zf.infolist():
with zf.open(info) as f:
print(info, np.load(f))

# Output:
# <ZipInfo filename='duplicate_key.npy' filemode='?rw-------' file_size=136> [1]
# <ZipInfo filename='duplicate_key.npy' filemode='?rw-------' file_size=144> [2 2]
# <ZipInfo filename='duplicate_key.npy' filemode='?rw-------' file_size=152> [3 3 3]

Error message:

No response

NumPy/Python version information:

1.21.2 3.8.11 (default, Aug 3 2021, 15:09:35)

[GCC 7.5.0]