为什么np.random.default_rng().permutation(n)优先于原始np.random.permutation(n)？
Numpy文档 on np.random.permutation建议所有新代码使用随机生成器包中的np.random.default_rng()。我在文档中看到，随机生成器包已经标准化了围绕着BitGenerator和使用Mersenne生成各种各样的随机发行版，这一点我很熟悉。
我看到了一个缺点，过去用一行代码来做简单排列：
np.random.permutation(10)现在变成两行代码，对于这样一个简单的任务来说，这感觉有点尴尬：
rng = np.random.default_rng()
rng.permutation(10)- 为什么这种新方法比以前的方法有所改进？
- 为什么像
np.random.permutation这样的现有方法不只是包装这个新的首选方法呢？ - 假设这个新方法不是在大容量下被调用的，那么是否有充分的理由不将它作为一个单行
np.random.default_rng().permutation(10)使用呢？ - 是否存在将现有代码切换到此方法的论点？
回答 1
Stack Overflow用户
发布于 2020-06-17 21:50:26
一些背景：
按照逻辑顺序回答你的问题：
为什么像np.random.permutation这样的现有方法不只是包装这个新的首选方法呢？
可能是因为向后兼容性问题。即使“顶级”API不会改变，它的内部结构也足以被认为是可压缩性的突破。
为什么这种新方法比以前的方法有所改进？
默认情况下，生成器使用PCG64提供的位，这比RandomState中使用的遗留MT19937具有更好的统计属性。(来源)。PCG64文档字符串提供了更多的技术细节。
假设这个新方法不是在大容量下被调用的，那么是否有充分的理由不将它作为一个单行
np.random.default_rng().permutation(10)使用呢？
我非常同意，如果它是在模块启动时完成的，那么这是一个有点尴尬的添加代码行。我只想指出，NumPy文档在docstring示例中确实直接使用这种形式，例如：
n = np.random.default_rng().standard_exponential((3, 8000))细微的区别是，一个类是在模块加载/导入时实例化的，而以您的形式，它可能会在稍后出现。但这应该是一个微小的差别(同样，假设它只使用了一次或几次)。如果您查看default_rng(seed)源代码，当使用None调用时，它只是在对seed进行几次快速检查之后返回Generator(PCG64(seed))。
是否存在将现有代码切换到此方法的论点？
我们将传递这一条，因为我没有更深入的技术知识来给算法提供一个很好的比较，也因为它取决于其他一些变量，比如您是否关心让您的下游代码与旧版本的NumPy兼容，而在旧版本中，default_rng()根本不存在。
https://stackoverflow.com/questions/62436859
复制相似问题
腾讯云开发者
