兼容性政策

numpy.random比 NumPy 的其余部分有更严格的兼容性政策。伪随机性的用户通常拥有能够在给定相同种子的情况下详细重现运行的用例（所谓的“流兼容性”），因此我们尝试平衡这些需求与增强算法的灵活性。NEP 19描述了该政策的演变。

我们强制执行的主要兼容性是在某些条件下运行之间的流兼容性。如果您使用相同的种子创建一个Generator相同的 BitGenerator，使用相同的参数执行相同的方法调用序列，在相同的版本上numpy，在相同的环境中，在同一台机器上，您应该获得相同的数字流。请注意，这些条件非常严格。有许多 NumPy 无法控制的因素限制了我们保证更多的能力。例如，不同的 CPU 实现浮点运算的方式不同，这可能会导致某些边缘情况存在差异，并级联到流的其余部分。Generator.multivariate_normal又如，使用 的矩阵分解numpy.linalg。即使在同一平台上，不同的版本也numpy可能使用与其链接到的 LAPACK 不同版本的矩阵分解算法，从而导致 Generator.multivariate_normal返回完全不同（但同样有效！）的结果。我们努力选择更能抵抗这些影响的算法，但这总是不完美的。

笔记

大多数Generator方法允许您从分布中提取多个值作为数组。出于上述策略的目的，该数组的请求大小是一个参数。拨打rng.random()5 次并不能保证给出与 相同的号码rng.random(5)。我们保留决定对不同大小的块使用不同算法的能力。实际上，这种情况很少发生。

与 NumPy 的其余部分一样，我们通常维护各个版本之间的 API 源兼容性。如果我们必须进行 API 破坏性更改，那么根据一般 NumPy 政策，我们只会在适当的弃用期和警告的情况下进行更改。

为了引入新功能或提高性能而破坏流兼容性的行为Generator将default_rng被谨慎 允许。此类更改将被视为功能，因此不会比功能的标准发布节奏更快（即在发布时，永远不会）。为此目的，缓慢不会被视为错误。像往常一样，在错误修复版本中可能会发生破坏流兼容性的正确性错误修复，但开发人员应该考虑是否可以等到下一个功能版本。我们鼓励开发人员强烈权衡用户因流兼容性中断而带来的痛苦与改进。值得改进的一个例子是改变算法以显着提高性能，例如，从高斯变量生成的Box-Muller 变换方法转向更快的Ziggurat 算法。不鼓励改进的一个例子是稍微调整 Ziggurat 表以实现小幅性能改进。X.YX.Y.Z

笔记

特别是，default_rng允许​​更改 BitGenerator它使用的默认值（再次强调，要谨慎并进行大量预先警告）。

一般来说，BitGenerator类对版本间流兼容性有更强的保证。这使得它们成为有需要的下游用户更坚实的构建模块。它们有限的 API 表面使他们更容易维护版本之间的兼容性。请参阅每个类的文档字符串BitGenerator以了解其各自的兼容性保证。

遗留功能RandomState和相关的便利功能具有更严格的版本间兼容性保证。由于NEP 19中概述的原因，我们在 NumPy 开发早期就对其版本间稳定性做出了更强有力的承诺。这种兼容性仍然有一些有限的用例（例如生成测试数据），因此我们尽可能保持兼容性。不会再有任何修改RandomState，甚至不会修复正确性错误。有一些灰色区域，我们可以进行一些小的修复，以便RandomState在 NumPy 内部发生变化时继续工作而不会出现段错误，以及一些文档字符串修复。然而，前面提到的关于机器与机器之间以及构建之间的可变性的警告仍然适用RandomState于Generator.