设置随机种子是标准建议,以便可以重现结果。但是,由于种子随着伪随机数的绘制而提前,因此如果任何一段代码绘制了一个额外的数字,结果可能会发生变化。
乍一看,版本控制似乎可以解决这个问题,因为它至少可以让您在您在笔记或论文中写下结果时返回并重现现有版本。但是,由于只需一次抽签就可以搞砸,如果您更新 R,结果也可能会发生变化。
我意识到这可能仅在极少数情况下才有问题,但我很好奇这里是否有任何最佳实践。这是我在自己的工作中一直在努力解决的问题。
设置随机种子是标准建议,以便可以重现结果。但是,由于种子随着伪随机数的绘制而提前,因此如果任何一段代码绘制了一个额外的数字,结果可能会发生变化。
乍一看,版本控制似乎可以解决这个问题,因为它至少可以让您在您在笔记或论文中写下结果时返回并重现现有版本。但是,由于只需一次抽签就可以搞砸,如果您更新 R,结果也可能会发生变化。
我意识到这可能仅在极少数情况下才有问题,但我很好奇这里是否有任何最佳实践。这是我在自己的工作中一直在努力解决的问题。
这取决于您将如何运行代码,或者是否有任何代码有点随机,因为它以随机方式绘制随机数。(这方面的一个例子是我们的vegan包中的排列测试,我们只继续排列,直到我们积累了足够的数据来知道结果是否与所述的类型 I 错误不同,并考虑到类型 II 错误率。)尽管即使这样应该不会影响抽奖...
如果最终脚本仅作为批处理作业或全部运行,并且没有来自伪随机数生成器的随机抽取,那么在脚本顶部设置种子并完整运行它是安全的.
如果您想单步执行代码,也许是重新运行块,那么您需要set.seed()
在每个将从伪随机数生成器中提取的函数调用之前进行调用。
对于我的科学论文,我通常会在每个代码块之前进行超级防御并设置种子;这允许在以后更新脚本,可能需要在任何时候插入到现有脚本中——比如回复审阅者或共同作者的评论。
希望您的结果不会取决于一组特定的伪随机值,因此问题在于能够重现报告或论文中所述的确切值。即使您可能非常防御并在每个代码块上设置了种子,您仍然可能需要重新创建确切的安装 --- R 版本和包版本,因此记录这些细节是必不可少的。为了更加安全,您需要为特定项目/论文保留以前的 R 版本和包。确实,很多人都是这样做的。