Windows 7下64位R的优化问题

如何解决Windows 7下64位R的优化问题

| 我目前处于开发我的第一个R包的最后阶段，该R包应该适合多项处理树（MPT）模型（有关当前版本，请参见其主页）。通过R \的“ 0”功能实现模型拟合。今天，我第一次在Windows 7机器上玩它，并发现了一些非常奇怪的东西：当使用64位版本的R时，optim无法成功收敛。这对我来说似乎是一个错误（尤其是nlminb都收敛了） R版本）。由于ѭ0是我程序包的核心，因此非常感谢您提供有关此问题的帮助。这是一个最小可复制的示例（通常，模型是通过表达式指定的，而不是在目标函数中指定的，但是为了简单起见，我将所有内容都放在了目标函数中）：

# The objective function:
llk.tree <- function (Q,data) 
{
    p <- Q[1]
    q <- Q[2]
    r <- Q[3]
    e <- rep(NA,4)
    e[1] <- p * q * r
    e[2] <- p * q * (1-r)
    e[3] <- p * (1-q) * r
    e[4] <- p * (1-q) * (1-r) + (1-p)

    llk <- sum(data * log(e))
    if (is.na(llk)) 
        llk <- -1e+19
    if (llk == -Inf) 
        llk <- -1e+19
    return(-llk)
}

# The call to optim:
optim(runif(3,0.1,0.9),llk.tree,data = c(24,65,30,61),method = \"L-BFGS-B\",lower = rep(0,3),upper = rep(1,3))

此示例复制了Riefer＆Batchelder关于MPT的开创性论文的示例，即表1 p中的第1行。 327（预期参数值为p = 1，q = 0.49，r = 0.30）。在32位R上运行它总是可以得到正确的结果（与版本2.12.2和2.13.0一起尝试）：

$par
[1] 1.0000000 0.4944449 0.3000001

$value
[1] 234.7110

$counts
function gradient 
      11       11 

$convergence
[1] 0

$message
[1] \"CONVERGENCE: REL_REDUCTION_OF_F <= FACTR*EPSMCH\"

（请注意，由于随机起始值，计数可能有所不同。）另一方面，在64位R上运行它可能会产生这样的（错误）结果：

$par
[1] 0.8668081 0.6326655 0.1433857

$value
[1] 257.7328

$counts
function gradient 
       3        3 

$convergence
[1] 0

$message
[1] \"CONVERGENCE: REL_REDUCTION_OF_F <= FACTR*EPSMCH\"

每次运行时，目标函数的返回值和参数值均不同，但计数始终为3！请注意，运行bit2ѭ会在32位和64位R上产生正确的结果：

nlminb(runif(3,lower = 0,upper = 1)

$par
[1] 1.0000000 0.4944445 0.3000000

$objective
[1] 234.711

$convergence
[1] 0

$iterations
[1] 14

$evaluations
function gradient 
      19       55 

$message
[1] \"relative convergence (4)\"

最后一点：我们有一些示例（这是我们最简单的示例模型），适用于64位R和optim，但更多示例（如此处所示的示例）不起作用。计数总是3 ... 编辑：固定起始值时（感谢约书亚·乌尔里希（Joshua Ulrich））optim不会偏离64位R下的那些固定值：

optim(c(0.5,0.5,0.5),3))

$par
[1] 0.5 0.5 0.5

$value
[1] 276.1238

$counts
function gradient 
       3        3 

$convergence
[1] 0

$message
[1] \"CONVERGENCE: REL_REDUCTION_OF_F <= FACTR*EPSMCH\"

解决方法

今天我们进行了更多测试，发现与使用64位R的Linux下的问题中描述的问题相同。但是，由于Joachim Vandekerckhove提出了这个巧妙的想法，我们尝试了一个简单的更改来解决了这个问题（尽管问题仍然很可疑）。在目标函数的末尾，如果llk是Inf，我们将其设置为极高的值（原为1e19）。使用较小的值（例如1e10）可以解决64位计算机上的问题（到目前为止已在Linux上进行了测试）：

llk.tree <- function (Q,data) 
{
    p <- Q[1]
    q <- Q[2]
    r <- Q[3]
    e <- rep(NA,4)
    e[1] <- p * q * r
    e[2] <- p * q * (1-r)
    e[3] <- p * (1-q) * r
    e[4] <- p * (1-q) * (1-r) + (1-p)

    llk <- sum(data * log(e))
    if (is.na(llk)) 
        llk <- -1e+10
    if (llk == -Inf) 
        llk <- -1e+10
    return(-llk)
}

# The call to optim:
optim(runif(3,0.1,0.9),llk.tree,data = c(24,65,30,61),method = \"L-BFGS-B\",lower = rep(0,3),upper = rep(1,3))

这将返回正确的结果！

Windows 7下64位R的优化问题

如何解决Windows 7下64位R的优化问题

解决方法

相关推荐