Hello,
I've come across what seems to be a bug in optim that has become a nuisance
for me.
To recreate the bug, run:
optim(c(0,0), function(x) {x[1]*1e-317}, lower=c(-1,-1), upper=c(1,1),
method='L-BFGS-B')
The error message says:
Error in optim(c(0, 0), function(x) { :
non-finite value supplied by optim
What makes this particularly treacherous is that this error only occurs for
specific powers. By running the following code you will find that the error
only occurs when the power is between -309 and -320; above and below that
work fine.
p <- 1:1000
giveserror <- rep(NA, length(p))
for (i in seq_along(p)) {
tryout <- try({
optim(c(0,0), function(x) {x[1]*10^-p[i]}, lower=c(-1,-1),
upper=c(1,1), method='L-BFGS-B')
})
giveserror[i] <- inherits(tryout, "try-error")
}
p[giveserror]
Obviously my function is much more complex than this and usually doesn't
fail, but this reprex demonstrates that this is a problem. To avoid the
error I may multiply by a factor or take the log, but it seems like a
legitimate bug that should be fixed.
I tried to look inside of optim to track down the error, but the error lies
within the external C code:
.External2(C_optim, par, fn1, gr1, method, con, lower,
upper)
For reference, I am running R 4.2.2, but was also able to recreate this bug
on another device running R 4.1.2 and another running 4.0.3.
Thanks,
Collin Erickson
[[alternative HTML version deleted]]
?s 17:30 de 23/12/2022, Collin Erickson escreveu:> Hello, > > I've come across what seems to be a bug in optim that has become a nuisance > for me. > > To recreate the bug, run: > > optim(c(0,0), function(x) {x[1]*1e-317}, lower=c(-1,-1), upper=c(1,1), > method='L-BFGS-B') > > The error message says: > > Error in optim(c(0, 0), function(x) { : > non-finite value supplied by optim > > What makes this particularly treacherous is that this error only occurs for > specific powers. By running the following code you will find that the error > only occurs when the power is between -309 and -320; above and below that > work fine. > > p <- 1:1000 > giveserror <- rep(NA, length(p)) > for (i in seq_along(p)) { > tryout <- try({ > optim(c(0,0), function(x) {x[1]*10^-p[i]}, lower=c(-1,-1), > upper=c(1,1), method='L-BFGS-B') > }) > giveserror[i] <- inherits(tryout, "try-error") > } > p[giveserror] > > Obviously my function is much more complex than this and usually doesn't > fail, but this reprex demonstrates that this is a problem. To avoid the > error I may multiply by a factor or take the log, but it seems like a > legitimate bug that should be fixed. > > I tried to look inside of optim to track down the error, but the error lies > within the external C code: > > .External2(C_optim, par, fn1, gr1, method, con, lower, > upper) > > For reference, I am running R 4.2.2, but was also able to recreate this bug > on another device running R 4.1.2 and another running 4.0.3. > > Thanks, > Collin Erickson > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-develHello, See if this R-Help thread [1] earlier this year is relevant. In particular, the post by R Core team member Luke Tierney [2], that answers much better than what I could. The very small numbers in your question seem to have hit a limit and this limit is not R related. [1] https://stat.ethz.ch/pipermail/r-help/2022-February/473840.html [2] https://stat.ethz.ch/pipermail/r-help/2022-February/473844.html Hope this helps, Rui Barradas
Collin, It is interesting that you get such strange results when passing denormal values to optim(). Several possibilities for this spring to mind. A better question though might be, "What kind of results are you expecting when you pass such small values to optim()?" In general, you shouldn't have a strong expectation that you'll get good results back when you have small coefficients like 1e-317 (or 1e-17) in your objective function. The algorithms behind optim() are not designed or implemented to do their best work with coefficients of magnitude far from 1. You can hope. You can get lucky. But I would not advise you to have strong expectations. -Steve On Fri, Dec 23, 2022 at 1:20 PM Collin Erickson <collinberickson at gmail.com> wrote:> Hello, > > I've come across what seems to be a bug in optim that has become a nuisance > for me. > > To recreate the bug, run: > > optim(c(0,0), function(x) {x[1]*1e-317}, lower=c(-1,-1), upper=c(1,1), > method='L-BFGS-B') > > The error message says: > > Error in optim(c(0, 0), function(x) { : > non-finite value supplied by optim > > What makes this particularly treacherous is that this error only occurs for > specific powers. By running the following code you will find that the error > only occurs when the power is between -309 and -320; above and below that > work fine. > > p <- 1:1000 > giveserror <- rep(NA, length(p)) > for (i in seq_along(p)) { > tryout <- try({ > optim(c(0,0), function(x) {x[1]*10^-p[i]}, lower=c(-1,-1), > upper=c(1,1), method='L-BFGS-B') > }) > giveserror[i] <- inherits(tryout, "try-error") > } > p[giveserror] > > Obviously my function is much more complex than this and usually doesn't > fail, but this reprex demonstrates that this is a problem. To avoid the > error I may multiply by a factor or take the log, but it seems like a > legitimate bug that should be fixed. > > I tried to look inside of optim to track down the error, but the error lies > within the external C code: > > .External2(C_optim, par, fn1, gr1, method, con, lower, > upper) > > For reference, I am running R 4.2.2, but was also able to recreate this bug > on another device running R 4.1.2 and another running 4.0.3. > > Thanks, > Collin Erickson > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Steven Dirkse, Ph.D. GAMS Development Corp. office: 202.342.0180 [[alternative HTML version deleted]]
The optim help page mentions scaling in the discussion of the "control" argument. Specifically under the parscale description: "Optimization is performed on par/parscale and these should be comparable in the sense that a unit change in any element produces about a unit change in the scaled value." In your function a unit change in x[1] makes a change of 1e-317 in the function value, and changing x[2] has no effect at all. It would be nice if violating the rule only led to inefficiencies or poor stopping decisions, but the numbers you are working with are close to the hardware limits (the smallest positive number with full precision is .Machine$double.xmin, about 2e-308), and sometimes that means assumptions in the code about how arithmetic works are violated, e.g. things like x*1.1 > x may not be true for positive x below .Machine$double.xmin . Duncan Murdoch On 23/12/2022 12:30 p.m., Collin Erickson wrote:> Hello, > > I've come across what seems to be a bug in optim that has become a nuisance > for me. > > To recreate the bug, run: > > optim(c(0,0), function(x) {x[1]*1e-317}, lower=c(-1,-1), upper=c(1,1), > method='L-BFGS-B') > > The error message says: > > Error in optim(c(0, 0), function(x) { : > non-finite value supplied by optim > > What makes this particularly treacherous is that this error only occurs for > specific powers. By running the following code you will find that the error > only occurs when the power is between -309 and -320; above and below that > work fine. > > p <- 1:1000 > giveserror <- rep(NA, length(p)) > for (i in seq_along(p)) { > tryout <- try({ > optim(c(0,0), function(x) {x[1]*10^-p[i]}, lower=c(-1,-1), > upper=c(1,1), method='L-BFGS-B') > }) > giveserror[i] <- inherits(tryout, "try-error") > } > p[giveserror] > > Obviously my function is much more complex than this and usually doesn't > fail, but this reprex demonstrates that this is a problem. To avoid the > error I may multiply by a factor or take the log, but it seems like a > legitimate bug that should be fixed. > > I tried to look inside of optim to track down the error, but the error lies > within the external C code: > > .External2(C_optim, par, fn1, gr1, method, con, lower, > upper) > > For reference, I am running R 4.2.2, but was also able to recreate this bug > on another device running R 4.1.2 and another running 4.0.3. > > Thanks, > Collin Erickson > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel