Question

我发现自己处于完成大量分析的位置，现在需要以稍微不同的输入假设重复分析。

在这种情况下，分析涉及聚类分析，绘制几个图，以及导出聚类ID和其他感兴趣的变量。关键是它是一个广泛的分析，需要重复和比较两次。

我考虑过：

创建一个功能。这并不理想，因为我必须修改我的代码才能知道我是在函数环境还是在父环境中进行评估。这种额外的努力似乎过多，使调试更加困难，并可能引入副作用。
将其包裹在for循环中。再次，不理想，因为那时我必须创建索引变量，这也可能引入副作用。
创建一些pre-amble代码，将分析包装在一个单独的文件中并source。这有效，但看起来非常丑陋且次优。

分析的目的是完成一组对象（在列表中，或在单独的输出文件中），我可以进一步分析差异。

处理此类问题的好策略是什么？

Answer 1

使代码可重用需要花费一些时间，精力并且还有一些额外的挑战，比如你自己提到的。

是否投资的问题可能是信息学中的关键问题（如果不是在很多其他领域）：我是否编写了一个脚本来以类似的方式重命名50个文件，或者我是否继续手动重命名它们。

我相信，答案非常个人化，即便如此，个案也不尽相同。如果您在编程上很容易，那么您可能会更快地决定使用重用路由，因为您的工作量相对较低（即便如此，程序员通常也喜欢学习新的技巧，因此这是一个隐藏的，通常会适得其反的动机）。

那就是说，在您的特定情况下：我会选择采购选项：因为您计划仅重复使用代码2倍，所以可能会浪费更多的努力（您表明分析相当广泛）。那么，如果它不是一个优雅的解决方案呢？没有人会看到你这样做，每个人都会对快速的结果感到满意。

如果在一年左右的时间内重复使用率高于预期，那么您仍然可以进行投资。到那时，您还将（至少）有三种情况，您可以将代码的重写和时髦可重用版本的结果与当前结果进行比较。

如果/当我事先知道我将重用代码时，我会在开发时尽量记住这一点。无论哪种方式，我几乎都不会编写不在函数中的代码（好吧，除了SO和其他开箱即用的分析的两行）：我发现这使我更容易构建我的想法。

Answer 2

如果可能的话，在外部参数文件中设置set / runs / experiments之间不同的参数。然后，您可以获取代码，调用函数，甚至使用包，但操作由一小组外部定义的参数确定。

例如，JSON非常适用于此，RJSONIO和rjson包允许您将文件加载到列表中。假设您将其加载到名为parametersNN.json的列表中。一个例子如下：

{
 "Version": "20110701a",
 "Initialization":
 {
   "indices": [1,2,3,4,5,6,7,8,9,10],
   "step_size": 0.05
 },
 "Stopping":
 {
   "tolerance": 0.01,
   "iterations": 100
 }
}

将其另存为“parameters01.json”并加载为：

library(RJSONIO)
Params <- fromJSON("parameters.json")

然后你就开始跑步了。（注意：我喜欢在我的参数文件中使用唯一版本#s，以便我可以稍后识别该集合，如果我正在查看R中的“参数”列表。）只需调用脚本并指向参数文件，例如：

Rscript --vanilla MyScript.R parameters01.json

然后，在程序中，从commandArgs()函数中识别参数文件。

稍后，您可以将代码分解为函数和包，但这可能是在短期内使vanilla脚本易于概括的最简单方法，并且这是一个长期的好习惯，因为代码应该与运行/数据集/实验相关参数的规范。

编辑：更准确地说，我甚至会在JSON中指定输入和输出目录或文件（或命名模式/前缀）。这使得一组参数如何导致一个特定输出集非常清楚。介于两者之间的所有内容都只是使用给定参数化运行的代码，但代码不应该真正改变太多，是不是应该这样做？

更新：三个月，以及数千次运行，比我之前的答案更明智，我会说JSON中的参数外部存储对于1-1000次不同的运行非常有用。当参数或配置数量在数千及以上时，最好切换到使用数据库进行配置管理。每个配置都可以源自JSON（或XML），但是能够应对不同的参数布局需要更大规模的解决方案，像SQLite这样的数据库（通过RSQLite）是一个很好的解决方案。

我意识到这个答案对于原始问题来说是过度的 - 如何重复工作几次，只需更改一些参数，但在正在进行的研究中扩展到数百或数千个参数变化时，需要更多的工具。：）

Answer 3

在这些情况下，我喜欢使用一个小shell脚本，一个pdf裁剪程序和Sweave。这会让你回报漂亮的报道，并鼓励你采购。通常我使用几个文件，几乎就像创建一个包（至少我觉得这样:)。我有一个单独的文件用于数据杂耍和单独的文件用于不同类型的分析，例如descriptiveStats.R，regressions.R。

这是我的小shell脚本，

 #!/bin/sh
 R CMD Sweave docSweave.Rnw
 for file in `ls pdfs`;
 do pdfcrop  pdfs/"$file" pdfs/"$file"
 done
 pdflatex docSweave.tex
 open docSweave.pdf

Sweave文件通常在需要时提供上述R文件。我不确定这是不是你要找的，但到目前为止这是我的策略。我至少相信创建透明，可重复的报告有助于至少遵循A策略。

Answer 4

你的第三个选择并不是那么糟糕。我在很多情况下这样做。您可以通过将预先填充的代码的结果放在环境中并附加要用于进一步分析的结构来构建更多结构。一个例子：

    setup1 <- local({
          x <- rnorm(50, mean=2.0)
          y <- rnorm(50, mean=1.0)
          environment()
          # ...
        })

    setup2 <- local({
          x <- rnorm(50, mean=1.8)
          y <- rnorm(50, mean=1.5)
          environment()
          # ...
        })

attach(setup1)并运行/获取您的分析代码

plot(x, y)
t.test(x, y, paired = T, var.equal = T)
...

完成后，detach(setup1)并附上第二个。

现在，至少你可以轻松地在设置之间切换。帮了我几次。

Answer 5

我倾向于将这些结果推到全球列表中。我使用Common Lisp但是R没有那么不同。

Answer 6

你在这里来得太晚了，但是我经常使用Sweave，而且很可能我从一开始就使用过Sweave文件（例如，如果我知道最终产品需要某种报告）。

对于第二次和第三次重复分析的部分，有两个选项：

如果结果相当“独立”（即应该生成3个报告，比较意味着报告并排检查），并且更改的输入以新数据文件的形式出现，进入自己的目录和Sweave文件的副本，我创建单独的报告（类似于源，但对于Sweave比对普通源感觉更自然）。
如果我宁愿在一个Sweave文件中再次做一次或两次完全相同的事情，我会考虑重用代码块。这类似于丑陋的for-loop。

原因在于，当然结果会在一起进行比较，这将是报告的最后部分。
如果从一开始就明白会有一些参数集和比较，我会以一种方式编写代码，一旦我对分析的每个部分都很好，它就会被包装成一个函数（即我在编辑器窗口中实际编写函数，但在编写函数时直接在工作区中评估行）。

鉴于你处于描述的情况，我同意尼克 - source没有任何问题，而其他一切意味着你已经将它作为脚本已经付出了更多的努力。

Answer 7

我无法对Iterator的答案发表评论，所以我必须在此发布。我非常喜欢他的回答，所以我创建了一个简短的脚本来创建参数并将它们导出到外部JSON文件。我希望有人认为这很有用：https://github.com/kiribatu/Kiribatu-R-Toolkit/blob/master/docs/parameter_configuration.md

重复大量分析的策略

7 个答案: