并行plyr中的奇怪环境行为

Question

最近,我已经创建了一个对象factor=1在我的工作区,不知道是有功能factor的base包.

我打算做的是factor在并行循环中使用变量,例如,

library(plyr)
library(foreach)
library(doParallel)

workers <- makeCluster(2)
registerDoParallel(workers,cores=2)

factor=1

llply(
  as.list(1:2),
  function(x) factor*x,
  .parallel = TRUE,
  .paropts=list(.export=c("factor"))
     )

然而,这会导致错误,让我有时间去理解.看起来,在environemt中plyr创建对象,但使用而不是用户提供的对象.请参阅以下示例factorexportEnvbase::factor

llply(
  as.list(1:2),
  function(x) {
    function_env=environment();
    global_env=parent.env(function_env);
    export_env=parent.env(global_env);
    list(
      function_env=function_env,
      global_env=global_env,
      export_env=export_env,
      objects_in_exportenv=unlist(ls(envir=export_env)),
      factor_found_in_envs=find("factor"),
      factor_in_exportenv=get("factor",envir=export_env)
      )
    },
  .parallel = TRUE,
  .paropts=list(.export=c("factor"))
  )

stopCluster(workers)

如果我们检查输出llply,我们看到该行factor_in_exportenv=get("factor",envir=export_env)不返回1(对应于用户提供的对象)而是函数定义base::factor.

问题1)我怎样才能理解这种行为？我原以为输出是1.

问题2)R如果我将一个新值分配给另一个包中已经定义的对象(例如我的情况下factor),是否有办法获得警告？

Answer 1

首先，我应该注意到，如果使用未在中使用的另一个变量名，错误就会消失base- 例如，如果我们使用a而不是factor. 这清楚地表明沿着其搜索路径在（值为 1 的变量）之前llply找到base::factor（函数） 。factor我试图用简化版本来复制这个问题llply，即

library(plyr)
library(foreach)
library(doParallel)

workers <- makeCluster(2)
registerDoParallel(workers,cores=2)

factor=1

llply_simple=function(.x,.fun,.paropts) {
  #give current environment a name
  tmpEnv=environment()
  attr(tmpEnv,"name")="llply_simple_body"
  #print all enclosing envirs of llply_simple_body (see def of allEnv below)
  print(allEnv(tmpEnv))
  cat("------\nResults:\n")
  do.ply=function(i) {
    .fun(i)
  }
  fe_call <- as.call(c(list(quote(foreach::foreach), i = .x), .paropts))
  fe <- eval(fe_call)
  foreach::`%dopar%`(fe, do.ply(i))
}

llply_simple使用递归辅助函数 ( allEnv) 循环遍历所有封闭环境。它返回一个包含所有环境名称的向量

allEnv=function(x) {
  if (environmentName(x)=="R_EmptyEnv") {
    return(environmentName(x))
  } else {
    c(environmentName(x),allEnv(parent.env(x)))
  }
}

有趣的是，简化的函数实际上按预期工作（即给出1和2作为结果）

llply_simple(1:2,function(x) x*factor,list(.export="factor"))
#[1] "llply_simple_body"  "R_GlobalEnv"        "package:doParallel" "package:parallel"  
#[5] "package:iterators"  "package:foreach"    "package:plyr"       "tools:rstudio"     
#[9] "package:stats"      "package:graphics"   "package:grDevices"  "package:utils"     
#[13] "package:datasets"   "package:methods"    "Autoloads"          "base"              
#[17] "R_EmptyEnv"
#--------
#Results:        
#[[1]]
#[1] 1
#
#[[2]]
#[1] 2

llply_simple因此，相对于完整功能的唯一显着区别plyr::llply是后者属于一个包。让我们尝试llply_simple进入一个包。

package.skeleton(list=c("llply_simple","allEnv"),name="llplyTest")
unlink("./llplyTest/DESCRIPTION")
devtools::create_description("./llplyTest",
                             extra=list("devtools.desc.author"='"T <t@t.com>"'))
tmp=readLines("./llplyTest/man/llply_simple.Rd")
tmp[which(grepl("\\\\title",tmp))+1]="Test1"
writeLines(tmp,"./llplyTest/man/llply_simple.Rd")
tmp=readLines("./llplyTest/man/allEnv.Rd")
tmp[which(grepl("\\\\title",tmp))+1]="Test2"
writeLines(tmp,"./llplyTest/man/allEnv.Rd")
devtools::install("./llplyTest")

现在尝试llplyTest::llply_simple从我们的新包执行llplyTest

library(llplyTest)
llplyTest::llply_simple(1:2,function(x) x*factor,list(.export="factor"))
#[1] "llply_simple_body"  "llplyTest"          "imports:llplyTest"  "base"              
#[5] "R_GlobalEnv"        "package:doParallel" "package:parallel"   "package:iterators" 
#[9] "package:foreach"    "package:plyr"       "tools:rstudio"      "package:stats"     
#[13] "package:graphics"   "package:grDevices"  "package:utils"      "package:datasets"  
#[17] "package:methods"    "Autoloads"          "base"               "R_EmptyEnv"
#------
#Results:
#Error in do.ply(i) : 
#  task 1 failed - "non-numeric argument to binary operator"

突然间，我们遇到了与 2013 年我最初的问题相同的错误。所以这个问题显然与从包中调用函数有关。让我们看一下 的输出allEnv：它基本上为我们提供了环境序列，llpy_simple并llplyTest::llpy_simple用于查找应导出的变量。实际上，正是它foreach进行了导出，如果有人有兴趣了解为什么foreach真正从我们命名的环境开始llply_simple_body，请查看 的源代码foreach::%dopar%，foreach:::getDoPar然后foreach:::.foreachGlobals$fun按照参数的路径进行操作envir。

我们现在可以清楚地看到，非包版本的搜索顺序与包版本的搜索顺序不同llplyTest::llpy_simple，包版本将factor首先找到base！