R devel - Oct 2016 - optim(?, method=?L-BFGS-B?) stops with an error

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.

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

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