BUG: Moore-Penrose 伪逆数的数值稳定性/一致性受到最近 OpenBLAS 活动的影响

我注意到下游存在一个测试失败，其中一个 机器学习 估计器执行了一个 `partial_fit`，该函数利用了 Moore-Penrose 伪逆来求解闭合形式（https://GitHub.com/lanl/GFDL/issues/117）。虽然只有 1/100 个元素不匹配，但相对容差差异很大（为 1.46476215），而之前的 NumPy/OpenBLAS 组合则不存在此问题。此失败始于 3 天前的 NumPy `2.5.0`，该版本搭载了新版 OpenBLAS。然后，我分析了一个纯文本，但相对较长的 NumPy 级别的重现。我将其推送到了 GitHub，地址为 https://GitHub.com/tylerjereddy/pinv_issue，它打印出了 NumPy `pinv` 输出的一个单元，该输入是一个固定的 2D 数组，它是从我们内部测试套件中精心提取的，该数组的纯文本大小是我提供其在单独仓库中的主要原因 - 它可能太大，无法在此处输出，因此您可以确认它是纯文本等。下面是它在几种不同场景中打印的结果 - 一致性的主要问题似乎与最新 x86_64 NumPy Linux 轮子中搭载的 OpenBLAS 有关，因为从源代码构建 NumPy `2.5.0` 与旧版 OpenBLAS 通过了我们的测试。我知道这些只是问题的“代理指标”，而不是完整的图像，特别是由于不同平台和不同线性代数后端的不同值是可以接受的，但尽管如此，NumPy `2.5.0` 与轮子中搭载的 OpenBLAS 在更广泛的测试中是不可接受的，因此我试图将此问题缩小到代理重现。仅仅为了强调一下 - 表中一些值不同是“可以的”，但 NumPy `2.5.0` + 与该轮子搭载的 OpenBLAS 的 `0.3609...` 值是“不可以的”（尽管这可能只是整个数值不稳定性问题的一部分）。很可能，输入数组在各种方面都具有病理特征，这对于批量输入和设计矩阵并不罕见。尽管如此，其他平台、线性代数后端和旧版 OpenBLAS 在我们进行的更广泛的数值测试中都表现得很好，我希望将代理测试重点放在单个浮点值上。