Problem with 64 bit R's optim under windows 7 - windows

Question

I am currently in the final phase of developing my first R package which is supposed to fit multinomial processing tree (MPT) models (see its homepage for the current version). The model fitting is achieved by R's optim function.
Today I was playing around with it for the first time on a windows 7 machine and noticed something really strange: optim does not converge succesfully when using the 64 bit version of R. This looks like a bug to me (especially as nlminb converges for both R versions). As optim is at the core of my package, any help on this question is greatly appreciated.
Here comes a minimally reproducible example (normally the model is specified via expressions and not specified in the objective function, but for simplicity I put everything in the objective function here):
# 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))
This example reproduces an example from a seminal paper on MPTs by Riefer & Batchelder, namely row 1 in Table 1 p. 327 (expected parameter values would be p = 1, q = .49 and r = .30).
Running it on a 32 bit R always gives the correct result (tried with versions 2.12.2 and 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"
(Note that count may differ due to random starting values.)
Running it on a 64 bit R on the other hand may produce such a (wrong) result:
$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"
The returned value of the objective function and the returned parameter values differ on each run, but count is always 3!
Note that running nlminb produces correct results on 32 bit and 64 bit R:
nlminb(runif(3, 0.1, 0.9), llk.tree, data = c(24, 65, 30, 61), 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)"
One final note: We have examples (this is our simplest example model) that worked on 64 bit R and optim but more examples (like the one shown here) did not work.
And count is always 3...
EDIT:
When fixing the starting values (thanks to Joshua Ulrich) optim does not move away from those fixed values under 64 bit R:
optim(c(0.5, 0.5, 0.5), llk.tree, data = c(24, 65, 30, 61), method = "L-BFGS-B", lower = rep(0, 3), upper = rep(1, 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"

Answer 1

We did some more testing today and found the same problem as described in the question under Linux using 64 bit R.
However, thanks to Joachim Vandekerckhove for this ingenious idea, we tried a simple change that solved the problem (although the issue remains suspicious). At the end of the objective function if llk is Inf we set it to an extremely high value (was 1e19).
Using a smaller value (e.g., 1e10) removes the problem on 64 bit machines (so far tested on 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))
This returns the correct result!