Skip to content

optimx and follow.on=TRUE... does not follow

2 messages · Marc Girondot, John C Nash

Original
Marc Girondot
# 
Hi,

I would like to know if some of you have a solution for this problem:

I use optimx (from package optimx) to fit the parameters of a model 
(complex model based on several imbricated exponential functions).

I use the two methods : method = c("Nelder-Mead", "BFGS") with the options:

control=list(dowarn=FALSE, follow.on=TRUE, kkt=FALSE, trace=1, 
REPORT=100, maxit=1000)

For some situations, it works as expected, but not for others.

The problem occurs at the transition between the two methods:

For example at the end of the Nelder-Mead method the value is 47.55839 
but at the beginning of the BFGS it drops again at 47.62xxx and at the 
end of the BFGS it is "only" 47.56198, so a local minimum (see below a 
result).

                  DHA      DHH     T12H    value fevals gevals niter 
convcode kkt1 kkt2  xtimes

Nelder-Mead 46.93154 39.94028 318.4949 47.55839    409     NA NA       
10   NA   NA 156.896
BFGS        45.29744 36.80026 321.5996 47.56198     54      5 NA        
0   NA   NA  32.604

After investigations, it seems that when parameters are transmitted from 
one method to the next, the values is truncated at the 5th digit. And as 
my model has several exponential functions imbricated, it is very 
sensitive to the precision of the parameters. It does not change the 
main conclusion, but I would prefer not have such a problem.

Does someone has a solution ?

I would prefer continue to use optimx.

Thanks a lot.

Marc
John C Nash
# 
"follow-on" is one of the main reasons I stopped work on optimx and refactored to optimr/optimrx, where I
separated this functionality into the polyopt() function. optimr has just a few solvers, while optimrx is used to
add them as I get round to doing it, but it's on R-forge. Mainly a matter of avoiding "your package
fails" when some dependency goes sick.

I am grateful that this posting has come, as I noted the Rd function for polyopt() had not been
completed. It is now mostly fixed on R-forge. I will do CRAN version when more tests are completed on
polyopt(). I'd be grateful for any feedback from users.

Marc: Can you try the polyopt from optimrx? I'll be happy to help with it, as I feel much more confident
there aren't collisions with other parts of the code. I tried and failed to fix optimx for the
kind of issue you found because there were (as far as I could determine) options that were incompatible.
I believe Ravi and I tried to go a step too far to integrate all the features in one function.

I'm hoping that polyopt doesn't truncate as you experienced, and am also willing to help sort that out.
I made the example in the polyopt manual page dump the function value at each evaluation, and the "best"
NM solution was passed to Rvmmin OK. But that is, after all, just one test.

Perhaps we should go off-list to work this out, then report back.

Best, JN
On 2017-05-17 12:29 PM, Marc Girondot via R-help wrote: