奇怪的 jags.parallel 错误/避免函数调用中的惰性求值

Posted 2023-02-19

【中文标题】奇怪的 jags.parallel 错误/避免函数调用中的惰性求值

【英文标题】：strange jags.parallel error / avoiding lazy evaluation in function call

【发布时间】：2013-05-19 08:24:51

【问题描述】：

我有一个函数调用（对jags.parallel），它在给定一个像n.iter = 100 这样的数字参数时有效，但在参数使用变量值n.iter = n.iter 时失败。这看起来可能是jags.parallel中的一个错误

错误的最小可重现示例：

    library(R2jags)
    model.file <- system.file(package="R2jags", "model", "schools.txt")
    J <- 8.0
    y <- c(28.4,7.9,-2.8,6.8,-0.6,0.6,18.0,12.2)
    sd <- c(14.9,10.2,16.3,11.0,9.4,11.4,10.4,17.6)    
    jags.data <- list("y","sd","J")
    jags.params <- c("mu","sigma","theta")
    jags.inits <- function()
      list("mu"=rnorm(1),"sigma"=runif(1),"theta"=rnorm(J))
    

然后这个工作：

    jagsfit.p <- jags.parallel(data=jags.data, inits=jags.inits, jags.params, 
                               n.iter=5000, model.file=model.file)

但这不是：

     n.iter=5000
    jagsfit.p <- jags.parallel(data=jags.data, inits=jags.inits, jags.params,
                               n.iter=n.iter, model.file=model.file)

给出错误：

Error in checkForRemoteErrors(lapply(cl, recvResult)) : 
  3 nodes produced errors; first error: object 'n.iter' not found

我认为这与未将变量 n.iter 导出到集群有关，但不清楚 jags.parallel 正在使用什么并行引擎。有什么方法可以欺骗 R 在将 n.iter 传递给函数之前对其进行评估？

【参考方案1】：

do.call() 在这种情况下是一个很好的朋友，因为（来自?do.call）：

如果 'quote' 是 'FALSE'，默认值，那么参数是 评估（在调用环境中，而不是在“环境”中）。

我确认以下工作，通过结果对象的打印方法显示的所有数字产生与您的jagsfit.p 匹配的结果：

jagsfit.p2 <- do.call(jags.parallel, 
                      list(data=jags.data, inits=jags.inits, jags.params,
                           n.iter=n.iter, model.file=model.file))

【讨论】：

如果数据实际上存储在一个列表中会怎样？ IE。如果您将所有数据都设为mydata=list(y=c(28.4,7.9,-2.8,6.8,-0.6,0.6,18.0,12.2), sd=c(14.9,10.2,16.3,11.0,9.4,11.4,10.4,17.6), J=8.0)？我之前运行过 jags(data=mydata, ETC.)，但是这里的 do.call 方法不起作用，因为在它搜索的环境中找不到名称。

@user29020 -- 抱歉，我没有使用足够的 jags 来让您的问题对我有快速的意义，而且没有其他人会在这里看到一个 2.5 年前的问题。我建议您在 SO 上将其作为一个问题，连同一个可重复的示例一起提出。 （你当然可以链接到这个问题并在你自己的问题中回答。）祝你好运！

感谢您的快速回复。我更喜欢保留旧的 SO/SE 问题以减少重复。无论如何，事实证明我的问题被问到了。我只是还没有找到它。这是：***.com/questions/23790452/…

@user29020 太好了！很高兴听到您发现了这一点，并感谢您在这里报告。正如您所说，将这些相关问题很好地相互关联是很好的。