[Rd] optim(?, method=?L-BFGS-B?) stops with an error

[Spencer Graves]

On 10/9/2016 9:00 AM, ProfJCNash wrote:
> I'll not copy all the previous material on this thread to avoid overload.
>
> The summary is that all the methods Spencer has tried have some issues.
>
> The bad news: This is not uncommon with optimization methods, in part because the problems are "hard",
> in part because getting them implemented and linked to an interfacing approach like R is very tedious
> and prone to omissions and errors.
>
> The good news: I've been working on a revision to optimx, having noted the implementation issues just
> mentioned. There is now a package optimr on CRAN, but that's just to reserve the name. The real package
> is optimrx on R-forge (dependencies can fail, then the poor maintainer gets "your package doesn't work",
> with no hope of fixing it). Moreover, Harry Joe recently pointed out to me a bug and in the last few
> weeks I think I've resolved issues where Rvmmin and other packages got NA results when numerical gradient
> approximations were used in certain ways.
>
> optimrx came about because I realized that optimx() has just enough difference in syntax from optim()
> to be a nuisance and was heavy to maintain. Also I wanted parameter scaling to work for all methods,
> as in optim(). However, Ravi's efforts easily convinced me that trying multiple methods was a
> good idea, so there is an opm() function. We also had an option for polyalgorithms and at one point
> for multiple starts. I've put them in polyopt() and multistart() -- the combination in optimx was
> driving me nuts when doing any work on the code. Ravi, I hope this doesn't offend. The optimx
> ideas are still there, but the restructuring will, I hope, lead to easier maintenance and development.
> As the package is very new, I fully expect there are some deficiencies, and ask that users send
> executable examples so I can address same.
>
> optimrx doesn't (yet) have nloptr. It's on the todo list, but I've not been able despite many tries to
> get any response from its maintainer (Jelmer Ypma), who seems to have largely dropped out of R work, though
> there was a fairly recent minor adjustment on Github. However, no communication is a
> worry, as nloptr and also ipoptr are important tools that could use support. I've offered, but I don't
> have C++ expertise. If anyone is willing to work with me, this can be moved forward soon.
>
> Spencer: Can you prepare your problem in a way that the optimization bit is replaceable and send to
> me? I'll see if I can figure out what is the actual source of the error as well as figure out what
> methods "work" and how well.


       Have you tried the following:


install.packages("Ecdat", repos="http://R-Forge.R-project.org")


       Then do "help(pac=Ecdat)" -> "User guides, package vignettes and 
other documentation" -> "Ecdat::AverageIncomeModels".


       This is a vignette that ends with one call to optim and two to 
optimx.  If you'd like to go to 
"https://r-forge.r-project.org/projects/ecdat/" and "Request to join", I 
will approve it as soon as I get the request.  Then you can edit that 
vignette directly.


       Thanks,
       Spencer
>
> Note that the Rtnmin package (a translation I made of my brother's Matlab code) also will handle
> bounds, but optimrx probably makes the call easier. If you send the example, I'll make sure it gets
> tried also.
>
> Best, JN