[Rd] bounds violations, infinite loops in optim/L-BFGS-B (PR#671)

[bolker@zoo.ufl.edu]

On Thu, 28 Sep 2000 ripley@stats.ox.ac.uk wrote:

> It's a feature, on the TODO list to be added one day.

  A quick hack (if anyone wants to do it) is to change line 975 from

/*	Rprintf("in lbfgsb - %s\n", task);*/

 to

	if (trace) Rprintf("in lbfgsb - %s\n", task);

however, the debugging output that you get is pretty ugly.

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

  Well, my question was more whether one was preferred or not ... I did
see a comment in some NEWS file at some point that a built-in function had
been switched to optim() and so should converge more often.

  At your suggestion I compiled optim.c (and ../appl/lbfgsb.c for good
measure) with -ffloat-store.  The negative parameter jumps went away, but
I can still provoke optim() to hang with the right (not uncommon) choice
of bootstrap values.  Adding what I thought were reasonable parscale
values makes my code hang in different places [i.e. the particular values
that I give below are no longer a problem], but doesn't stop it hanging or
even reduce the frequency with which it hangs.  Perhaps now that I have
ffloat-store enabled the values below will hang under Solaris as well.

  Should ffloat-store be enabled in general for compilation on Linux
boxes?

  Just for the record, the apparent internal behavior (which I extracted
by uncommenting/modifying line 975 of optim.c as above) is that the
routine does task FG_START, followed by 20 FG_LNSRCH, followed by
ABNORMAL_TERMINATION_IN_LNSRCH, then repeats this indefinitely.  I
wouldn't mind so much if optim/lbfgsb looped until a maximum number of
iterations and then stopped with an error code, but as it stands these
particular cycles never make it to an iteration check and so the loop
never stops -- in order to do the bootstrap run I have to sit and hit
Ctrl-C to restart every time it looks like it's hanging.

  I agree that supplying derivatives would probably fix the problem
(parscale doesn't seem to help enough to fix the problem), but I'm in part
trying to provide this as a tool for non-analytically-inclined students
and I don't want to have to hold their hands while they take the
derivatives of their functions ...

 I greatly appreciate the time that you, and the rest of the core team,
have put into R.

  Ben Bolker

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

nllfun2g.boot_function(q,debug=FALSE){
  N1_q[1]
  N2_q[2]
  G_q[3]
  maxval <- 1e8
  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))
  r[!is.finite(r)] <- maxval*sign(r[!is.finite(r)])
  r
}
  
debug <- FALSE
trace <- TRUE
fuzz <- 0.001

## hangs

boot.pred <- c(53,73,73,44,22,31,73,22,53,53,91,73)
boot.total <- c(200,500,100,900,150,200,500,150,200,200,900,100)

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=trace),debug=debug))


-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._