The results are very sensitive in some cases to configuration (tolerances,
etc.) and problem.
Are you using the "follow-on" option? That will definitely be order dependent.
optimx is currently under review by Ravi Varadhan and I. Updating optimx proved
very difficult
because of interactions between different options, so I introduced optimr, with
version optimrx
on R-forge to have more solvers. When solvers were "down" on CRAN the codes
would sometimes give
trouble, but we think we can check for this now. Also we want to leave optimx
present because a
number of people are using it, so that function will be part of the updated
package which will
be called optimx, and optimr/rx will be deprecated to reduce the package count.
There is still work to be done, though we think it is now more or less fixed,
and I can send
a tarball if desired. We'd welcome feedback. The new structure uses a single
function optimr()
that can call any one of nearly 2 dozen solvers, and function opm() will do
what optimx does for
multiple methods. opm() simply loops through optimr() for each method. A big
change is that
optimr() uses the optim() syntax INCLUDING parscale for all methods. The
"follow-on"
polyalgorithm and multiple starts are in separate functions to avoid the
interaction that was
giving me maintenance issues with the optimx function (and which could give
strange behaviour
with optimx() now, so multiple features at once is likely suspect).
If you have gradients, I recommend using Rvmmin (callable from optimr()) or a
method that can
use gradients. If you have bounds, do use a method with bounds capability.
No gradient, then BOBYQA from minqa (also callable from optimx() or optimr())
can often be
very efficient, but is quirky and occasionally gives rubbish in my experience.
Cheers, JN
On 2017-12-31 09:03 AM, Marc Girondot via R-help wrote:
> Dear R-er,
>
> For a non-linear optimisation, I used optim() with BFGS method but it stopped
> regularly before to reach a true mimimum.
> It was not a problem with limit of iterations, just a local minimum. I was
> able sometimes to reach better minimum using
> several rounds of optim().
>
> Then I moved to optimx() to do the different optim rounds automatically using
> "Nelder-Mead" and "BFGS" methods
>
> I find a huge time difference using system.time() based on the order of these
> both methods:
>
>> snb # "Nelder-Mead" and "BFGS"
> user system elapsed
> 1021.656 0.200 1021.695
>> sbn # "BFGS" and "Nelder-Mead"
> user system elapsed
> 3140.096 0.384 3139.728
>
> But optimx() with "Nelder-Mead" and "BFGS" stops in local minimum:
>
>> o_mu2p1$value
> [1] 2297.557
>
> whereas "BFGS" and "Nelder-Mead" stops in better model (not sure if it is a
> global minimum, but it is better):
>
>> o_mu2p1$value
> [1] 2297.305
>
> ####################
>
> My questions are:
>
> Are my findings common and documented (order of methods giving non consistant
> results) or are they specific to the model
> I try to fit ?
>
> If it is known problem, where I can find the best advice about order of
> methods ?
>
> ####################
>
> To reproduce what I said:
>
> install.packages("http://www.ese.u-psud.fr/epc/conservation/CRAN/HelpersMG.tar.gz";,
> repos=NULL, type="source")
> install.packages("http://www.ese.u-psud.fr/epc/conservation/CRAN/phenology.tar.gz";,
> repos=NULL, type="source")
>
> library("phenology")
> library("car")
> library("optimx")
> library("numDeriv")
>
> ECFOCF_2002 <- TableECFOCF(MarineTurtles_2002)
> snb <- system.time(
> o_mu2p1_nb <- fitCF(par = structure(c(0.244863062899293,
> 43.5578630363601,
> 4.94764539004454,
> 129.606771856887,
> -0.323749593604171,
> 1.37326091618759),
> .Names = c("mu1", "size1", "mu2",
> "size2", "p", "OTN")),
> method = c("Nelder-Mead", "BFGS"),
> data=ECFOCF_2002, hessian = TRUE)
> )
> sbn <- system.time(
> o_mu2p1_bn <- fitCF(par = structure(c(0.244863062899293,
> 43.5578630363601,
> 4.94764539004454,
> 129.606771856887,
> -0.323749593604171,
> 1.37326091618759),
> .Names = c("mu1", "size1", "mu2",
> "size2", "p", "OTN")),
> method = c("BFGS", "Nelder-Mead"),
> data=ECFOCF_2002, hessian = TRUE)
> )
>
> snb
> o_mu2p1_nb$value
>
> sbn
> o_mu2p1_bn$value
>
> ______________________________________________
> R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
______________________________________________
R-help@r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
