兼容性策略

numpy.random 相比 NumPy 的其他部分,具有稍微严格的兼容性策略.伪随机数的用户通常需要能够在给定相同种子的情况下,以精细的细节重现运行(所谓的“流兼容性”),因此我们尝试在这些需求与增强算法的灵活性之间取得平衡. 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 的更改,那么我们只会根据 general NumPy policy ,在适当的弃用期和警告之后进行.

为了引入新功能或提高 Generator 或 default_rng 的性能而破坏流兼容性是被允许的,但需要谨慎.此类变更将被视为功能,因此不会比功能的标准发布节奏更快(即在 X.Y 版本上,永远不会在 X.Y.Z 版本上).为此,速度慢不会被认为是错误.破坏流兼容性的正确性错误修复可以像往常一样在错误修复版本上发生,但开发人员应该考虑是否可以等到下一个功能版本.我们鼓励开发人员强烈权衡用户因流兼容性中断而产生的痛苦与改进的好处.一个值得改进的例子是更改算法以显着提高性能,例如,将高斯变量生成的 Box-Muller transform 方法更改为更快的 Ziggurat algorithm .一个不鼓励进行的改进的例子是稍微调整 Ziggurat 表以获得小的性能改进.

备注

特别是,允许 default_rng 更改它使用的默认 BitGenerator (同样,要谨慎并提前充分警告).

通常, BitGenerator 类具有更强的版本间流兼容性保证.这使得它们可以成为下游用户所需的一个更可靠的构建块.它们有限的 API 表面使其更容易保持版本间的兼容性.有关每个 BitGenerator 类的单独兼容性保证,请参见其文档字符串.

遗留的 RandomState 和 associated convenience functions 具有更严格的版本间兼容性保证.由于 NEP 19 中概述的原因,我们在 NumPy 开发的早期就对其版本间的稳定性做出了更强的承诺.对于这种兼容性仍然存在一些有限的用例(例如为测试生成数据),因此我们尽可能地保持兼容性. RandomState 将不再进行修改,甚至不会修复正确性错误.在一些灰色地带,我们可以进行小的修复,以保持 RandomState 在 NumPy 内部结构发生变化时正常工作,而不会发生段错误,以及进行一些文档字符串的修复.然而,前面提到的关于机器间和构建间可变性的警告仍然适用于 RandomState ,就像它适用于 Generator 一样.