兼容性政策

numpy.random 比 NumPy 的其他部分有更严格的兼容性政策.伪随机性的用户通常有在给定相同种子的情况下能够详细重现运行的用例（所谓的”流兼容性”）,因此我们试图在增强算法的灵活性与满足这些需求之间取得平衡.:ref:NEP 19 描述了这一政策的演变.

我们强制执行的主要兼容性类型是在某些条件下从运行到运行的流兼容性.如果你使用相同的 BitGenerator 和相同的种子创建一个 Generator,执行相同的方法调用序列并使用相同的参数,在同一版本的 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 中引入新功能或提高性能而打破流兼容性将被 允许 ,但需 谨慎 .此类更改将被视为功能,因此不会比标准功能发布节奏更快（即在 X.Y 版本中,绝不在 X.Y.Z 中）.在此目的下,慢速不会被视为错误.根据惯例,修复破坏流兼容性的正确性错误可以在错误修复版本中进行,但开发者应考虑是否可以等到下一个功能发布.我们鼓励开发者强烈权衡用户因流兼容性中断而感到的痛苦与改进.一个值得改进的例子是改变算法以显著提高性能,例如,从 Box-Muller 变换 方法的正态变量生成改为更快的 Ziggurat 算法.一个不鼓励的改进例子是对 Ziggurat 表进行微调以获得小幅性能提升.

备注

特别是,`default_rng` 允许更改其使用的默认 `BitGenerator`（同样,需要 谨慎 并在大量提前警告的情况下进行）.

一般来说,`BitGenerator` 类在版本间的流兼容性方面有更强的保证.这使得它们成为需要这种兼容性的下游用户的更稳固的构建块.它们有限的API表面使得它们更容易在版本间保持这种兼容性.请参阅每个 BitGenerator 类的文档字符串,了解它们各自的兼容性保证.

遗留的 RandomState 和 相关的便捷函数 有一个更严格的版本间兼容性保证.由于在 NEP 19 中概述的原因,我们在 NumPy 早期开发中对它们的版本间稳定性做出了更强的承诺.这种兼容性在某些有限的用例中仍然存在（例如生成测试数据）,因此我们尽可能地保持兼容性.不会再对 RandomState 进行修改,甚至不会修复正确性错误.在 NumPy 内部变化时,我们可以在一些灰色区域进行小的修复以保持 RandomState 正常工作而不发生段错误,以及一些文档字符串的修复.然而,之前提到的关于机器间和构建间可变性的注意事项同样适用于 RandomState 和 Generator.