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
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
