similar to: optim(method="L-BFGS-B") abnormal termination

[sorry, forgot some details...] I'm using optim(param, fun, method='L-BFGS-B', lower=lo, upper=up) to minimize a certain function. Often the minimization ends with the message: ERROR: ABNORMAL_TERMINATION_IN_LNSRCH What is optim() trying to say? What have I to change in my function to make the minimization succeed? Do you think using BBoptim() instead of optim() changes anything?

I am using the function optim and I get the error message ABNORMAL_TERMINATION_IN_LNSRCH. Reason for this could be a scaling problem. Thus, I used parscale in order to scale the parameters. But I still have the error message. For example, with parscale=c(rep(1,n), 0.01,1,0.01): return(optim(c(mu1,b,k,phi), neg2loglikelihood, method = "L-BFGS-B",

Hi - I am doing some monte carlo simulations comparing bayesian (using Plummer's jags) and maximum likelihood (using lmer from package lme4 by Bates et al). I would like to know if there is a way I can flag nonconvergence and exceptions. Currently the simulations just stop and the output reads things like: Error in optim(.Call("lmer_coef", x, 2, PACKAGE = "Matrix"), fn,

Hello, I've just a little problem using the function optim. Here is the function I want to optimize : test_function(x){(exp(-0.06751 + 0.25473*((x[1]-350)/150) + 0.04455*((x[2]-40)/20) + 0.09399*((x[3]-400)/100) - 0.17238*((x[4]-250)/50)- 0.45984*((x[5]-550)/150)-0.39508*((x[1]-350)/150)* ((x[1]-350)/150) - 0.05116*((x[2]-40)/20)* ((x[2]-40)/20) - 0.27735*((x[3]-400)/100)*((x[3]-400)/100) -

Dear all, when using optim() for a function that uses the parent environment, I see the following unexpected behavior: makeFn <- function(){ ??? xx <- ret <- NA ??? fn <- function(x){ ?????? if(!is.na(xx) && x==xx){ ?????????? cat("x=", xx, ", ret=", ret, " (memory)", fill=TRUE, sep="") ?????????? return(ret) ?????? } ?????? xx

Full_Name: Jörg Polzehl Version: 1.5.1 OS: Windows 2000 Submission from: (NULL) (193.175.148.198) When calculating MLE's in a variance component model using constrained optimization, i.e. optim(...,method="L-BFGS-B",...) I observed an inproper behaviour in cases where the likelihood function was evalueted at the constraint. Parameters and value of the function at the constraint

On 03/05/2019 10:31, Serguei Sokol wrote: > On 02/05/2019 21:35, Florian Gerber wrote: >> Dear all, >> >> when using optim() for a function that uses the parent environment, I >> see the following unexpected behavior: >> >> makeFn <- function(){ >> ???? xx <- ret <- NA >> ???? fn <- function(x){ >> ??????? if(!is.na(xx)

On 02/05/2019 21:35, Florian Gerber wrote: > Dear all, > > when using optim() for a function that uses the parent environment, I > see the following unexpected behavior: > > makeFn <- function(){ > ??? xx <- ret <- NA > ??? fn <- function(x){ > ?????? if(!is.na(xx) && x==xx){ > ?????????? cat("x=", xx, ", ret=", ret, "

I try to code the ULS factor analysis descrbied in ftp://ftp.spss.com/pub/spss/statistics/spss/algorithms/ factor.pdf # see PP5-6 factanal.fit.uls <- function(cmat, factors, start=NULL, lower = 0.005, control = NULL, ...) { FAfn <- function(Psi, S, q) { Sstar <- S - diag(Psi) E <- eigen(Sstar, symmetric = TRUE, only.values = TRUE) e <- E$values[-(1:q)] e <-

Your results below make it look like a bug in optim(): it is not duplicating a value when it should, so changes to x affect xx as well. Duncan Murdoch On 03/05/2019 4:41 a.m., Serguei Sokol wrote: > On 03/05/2019 10:31, Serguei Sokol wrote: >> On 02/05/2019 21:35, Florian Gerber wrote: >>> Dear all, >>> >>> when using optim() for a function that uses the

Hi I have a FORTRAN version of the L-BFGS-B algorithm and I was comparing it to the code in the lbfgsb.c file available at R-4.0.0.tar.gz Everithing looks the same, except for those two lines that must be printed by the prn3lb function in case of an error (lines 3559 and 3561 in lbfgsb.c): case -5: Rprintf("l(%d) > u(%d). No feasible solution", k, k); break; case -7:

Yes, I think you are right. I was at first confused by the fact that after the optim() call, > environment(fn)$xx [1] 10 > environment(fn)$ret [1] 100.02 so not 9.999, but this could come from x being assigned the final value without calling fn. -pd > On 3 May 2019, at 11:58 , Duncan Murdoch <murdoch.duncan at gmail.com> wrote: > > Your results below make it look like a

It looks as though this happens when calculating numerical gradients: x is reduced by eps, and fn is called; then x is increased by eps, and fn is called again. No check is made that x has other references after the first call to fn. I'll put together a patch if nobody else gets there first... Duncan Murdoch On 03/05/2019 7:13 a.m., peter dalgaard wrote: > Yes, I think you are

That's consistent/not surprising if the problem lies in the numerical gradient calculation step ... On 2019-05-06 10:06 a.m., Ravi Varadhan wrote: > Optim's Nelder-Mead works correctly for this example. > > >> optim(par=10, fn=fn, method="Nelder-Mead") > x=10, ret=100.02 (memory) > x=11, ret=121 (calculate) > x=9, ret=81 (calculate) > x=8, ret=64

Dear kind R-experts. Does anybody have an experience to use optim function? If yes, what is the main difference between two method "BFGS" vs "L-BFGS-B"? I used "BFGS" method and got what I wanted. But when I used "L-BFGS-B" the error message said that "L-BFGS-B needs finite values of fn". So that means "BFGS" method can handle even if fn

It seems that it's an old bug that was found in some other packages, but at that time not optim: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15958 and that Duncan Murdoch posted a patch already last Friday :) Thomas Am 06.05.2019 um 16:40 schrieb Ben Bolker: > That's consistent/not surprising if the problem lies in the numerical > gradient calculation step ... >

The the use of optim with the L-BFGS-B method for the following simple function gives erroneous results. Any help appreciated! Best, Bob Reilly # Code: V=function(p){ p1=p[1];p2=p[2] y=p1*p2-.4*(p1+p2) return(-y)} p=c(.2,.2) # p=c(.8,.8) max=optim(p,V,method = "L-BFGS-B",lower=c(0,0),upper=c(1,1)) max1=optim(max$par,V,method = "L-BFGS-B",lower=c(0,0),upper=c(1,1))

>>>>> Spencer Graves <spencer.graves at prodsyse.com> >>>>> on Sat, 8 Oct 2016 18:03:43 -0500 writes: [.............] > 2. It would be interesting to know if the > current algorithm behind optim and optimx with > method='L-BFGS-B' incorporates Morales and Nocedal (2011) > 'Remark on ?Algorithm 778:

Optim's Nelder-Mead works correctly for this example. > optim(par=10, fn=fn, method="Nelder-Mead") x=10, ret=100.02 (memory) x=11, ret=121 (calculate) x=9, ret=81 (calculate) x=8, ret=64 (calculate) x=6, ret=36 (calculate) x=4, ret=16 (calculate) x=0, ret=0 (calculate) x=-4, ret=16 (calculate) x=-4, ret=16 (memory) x=2, ret=4 (calculate) x=-2, ret=4 (calculate) x=1, ret=1

Hi, When using method L-BFGS-B along with a parscale argument, should the lower and upper bounds provided be on the scaled or unscaled values? Thanks. Cheers, -- Seb