R devel - Sep 2000 - bounds violations, infinite loops in optim/L-BFGS-B (PR#671)

I'm having some trouble with optim(method="L-BFGS-B"),
and I'm not sure I have the ability to track down and fix
what seem to be bugs within optim().
  I'm bootstrapping an original data set and fitting a model
to each bootstrapped data set.  For some bootstrapped samples,
optim() sets negative parameter values (despite the fact that
I have explicitly set non-zero lower bounds on the parameters)
and chokes.  For other samples, it appears to get into an infinite
loop (ignoring the finite value of maxit).
 
  Functions and samples that provoke the problem are below: I
was able to reproduce the problems running this with --vanilla.

  Not exactly a bug but: there is no tracing information built
into L-BFGS-B (setting trace=TRUE has no effect).

  Also, a general question: are both nlm() and optim() going to
be around indefinitely?  Should I be using one or the other?

  For the moment I've managed to (sort of) get around the problem
with try(), but the infinite loops are a real nuisance ...

cfunc2_function(input,N1,N2,G=1.0){
  pmin(1,1/((1+((input - N1)/N2))^G))
}

nllfun2g.boot_function(q,debug=FALSE){
#  if (i==93) debug <- TRUE
  N1_q[1]
  N2_q[2]
  G_q[3]
  L_cfunc2(boot.total,N1,N2,G)
  if (debug) cat(c(N1,N2,G,range(L)),"\n")
  r <- -sum(dbinom(boot.pred, boot.total, L, log=TRUE))
  if (!is.finite(r)) {
    cat(c(N1,N2,G,range(L)),"\n")
    cat(boot.pred,"\n")
    cat(boot.total,"\n")
    cat(L,"\n")
    cat(dbinom(boot.pred, boot.total, L, log=TRUE),"\n")
  }
  r
}

fuzz <- 0.001

boot.pred <- c(91,22,44,31,47,83,31,56,22,83,53,73)
boot.total <- c(900,150,900,200,150,100,200,300,150,300,200,500)
n <- try(optim(c(min(boot.total)-1,100,1),nllfun2g.boot,
        lower=rep(fuzz,3),upper=c(min(boot.total)-fuzz,Inf,Inf),
           method="L-BFGS-B",control=list(trace=TRUE),debug=TRUE))

boot.pred <- c(31,73,56,22,22,56,83,22,83,91,30,44)
boot.total <- c(200,100,300,150,150,300,100,150,300,900,500,900)
n <- optim(c(min(boot.total)-1,100,1),nllfun2g.boot,
        lower=rep(fuzz,3),upper=c(min(boot.total)-fuzz,Inf,Inf),
           method="L-BFGS-B",control=list(trace=TRUE),debug=TRUE)


--please do not edit the information below--

Version:
 platform = i686-pc-linux-gnu
 arch = i686
 os = linux-gnu
 system = i686, linux-gnu
 status = 
 major = 1
 minor = 1.1
 year = 2000
 month = August
 day = 15
 language = R

Search Path:
 .GlobalEnv, Autoloads, package:base

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

> From: bolker@zoo.ufl.edu
> Date: Tue, 26 Sep 2000 16:14:13 +0200 (MET DST)
> 
>   I'm having some trouble with optim(method="L-BFGS-B"),
> and I'm not sure I have the ability to track down and fix
> what seem to be bugs within optim().
>   I'm bootstrapping an original data set and fitting a model
> to each bootstrapped data set.  For some bootstrapped samples,
> optim() sets negative parameter values (despite the fact that
> I have explicitly set non-zero lower bounds on the parameters)
> and chokes.  For other samples, it appears to get into an infinite
> loop (ignoring the finite value of maxit).
>  
>   Functions and samples that provoke the problem are below: I
> was able to reproduce the problems running this with --vanilla.
> 
>   Not exactly a bug but: there is no tracing information built
> into L-BFGS-B (setting trace=TRUE has no effect).
It's a feature, on the TODO list to be added one day.
>   Also, a general question: are both nlm() and optim() going to
> be around indefinitely?  Should I be using one or the other?
There are no plans to remove either.  `indefinitely' is not part
of the non-warranty.
 
>   For the moment I've managed to (sort of) get around the problem
> with try(), but the infinite loops are a real nuisance ...
On Solaris, I get neither negative values nor an infinite loop
on your examples. 

On Linux RH6.2/gcc 2.95.2 I get

NA 1 NA 1 1 1 1 0.6831783 1 0.6831783 1 NA 
NA -Inf NA -Inf -Inf -Inf -Inf -160.2173 -Inf -107.0805 -Inf NA 
Error in optim(c(min(boot.total) - 1, 100, 1), nllfun2g.boot, lower = rep(fuzz,
: 
        L-BFGS-B needs finite values of fn

for the first, and probably a loop for the second.  I think this is
the usual problem with inconsistent internal precision on Linux
compilers, so try compiling optim.c with -ffloat-store to make gcc
IEEE-compliant.  (At least, that's what the Linux gcc man page says.)

Can you provide some evidence for negative parameter values?  That's
not supposed to happen, but as I rarely fail to supply derivatives,
I have not tested it much.

Finally, I think you have omitted to supply scaling consts for your problem,
and optim will work a lot better if you do, as it will also do if
you can supply analytical derivatives.

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._

> From: ben@zoo.ufl.edu
> Date: Tue, 3 Oct 2000 11:45:37 -0400 (EDT)
[...]
>   On the other hand, I might choose to work on adapting a different set of
> code -- the "nlminb" function in Splus5 appears to be based on a
different
> set of Netlib FORTRAN code (dmnfb,dmngb,dmnhb) -- don't know the
> particular reasons for using a different algorithm here.
1) The one used in optim is later and supposedly better.

2) I do try not to copy S-PLUS (as distinct from S).

3) There are quite a few problems with nlminb too.

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To:
r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._