Skip to content

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

2 messages · Brian Ripley, Ben Bolker

Original
Brian Ripley
# 
It's a feature, on the TODO list to be added one day.
There are no plans to remove either.  `indefinitely' is not part
of the non-warranty.
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.
1 day later
Ben Bolker
#
On Thu, 28 Sep 2000 ripley@stats.ox.ac.uk wrote:

            

      
      
      
    

        
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.

            

      
      
      
    

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