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

[ProfJCNash]

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

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [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


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] optim(…, method=‘L-BFGS-B’) stops with an error message while violating the lower bound

[Ravi Varadhan]

Spencer,
Another option is to try the "lbfgs" package.  Hans Werner Borchers has told me 
that this is a good implementation of L-BFGS.
Best,
Ravi

From: R-devel  on behalf of Spencer Graves 

Sent: Saturday, October 8, 2016 7:03 PM
To: Mark Leeds
Cc: R-devel
Subject: Re: [Rd] optim(…, method=‘L-BFGS-B’) stops with an error message while 
violating the lower bound

Hi, Mark et al.:


   Thanks, Mark.


   Three comments:


 1.  Rvmmin was one of the methods I tried after Ravi
directed me to optimx.  It returned NAs for essentially everything. See
my email of this subject stamped 4:43 PM Central time = 21:43 UTC.


 2.  It would be interesting to know if the current
algorithm behind optim and optimx with method='L-BFGS-B' incorporates
Morales and Nocedal (2011) 'Remark on “Algorithm 778: L-BFGS-B: Fortran
Subroutines for Large-Scale Bound Constrained Optimization”'.  I created
this vignette and started this threat hoping that someone on the R Core
team might decide it's worth checking things like that.


 3.  The vignette mentioned below was extracted from a
larger vignette fitting several models that seem to encounter
convergence problems.  I should probably switch to optimx using all the
methods that offers for constrained optimization, including nminb.


   Best Wishes,
   Spencer Graves


On 10/8/2016 5:00 PM, Mark Leeds wrote:
> Hi Spencer: See the link below about L-BFGS-B below because  I had
> problems
> with it a good while back (and I think the link description is the
> cause but I can't prove it )  so  eventually I moved to the  Rvmmin(b)
> package. It's a package but really an algorithm. Rvmmin(b) uses a
> variable-metric algorithm similar to that of L-BFGS-B but without the
> problem below. It's not surprisingly a creation of John Nash and quite
> impressive based on my experience. Just like L-BFGS, it can implement
> box constraints by adding the b.
>
> http://users.eecs.northwestern.edu/~morales/PSfiles/acm-remark.pdf
> 
>
>
>
>
>
>
>
> On Sat, Oct 8, 2016 at 2:50 PM, Spencer Graves
> mailto:spencer.gra...@prodsyse.com>> wrote:
>
> Hello:
>
>
>   The development version of Ecdat on R-Forge contains a
> vignette in which optim(…, method=‘L-BFGS-B’) stops with an error
> message while violating the lower bound.
>
>
>   To see all the details, try 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".
>
>
>   I've found other optimizers that will get around the problem
> in this case but none that performs as well as optim with many
> other problems.
>
>
>   Thanks,
>   Spencer Graves
>
>
> p.s.  I've also tested bobyqa{minqa} or nloptr{nloptr},
> recommended in a vignette in the lme4 package.  These did better
> than optim in this example but worse in others I tried.
>
> __
> R-devel@r-project.org  mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>
>


[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel