[Rd] optim(method="L-BFGS-B"...) (PR#3000)

[foote at geosci.uchicago.edu]

Full_Name: Michael Foote
Version: 1.7.0
OS: Redhat 6.1
Submission from: (NULL) (128.135.227.70)


I am running R1.7.0, compiled from source code on Redhat Linux 6.1.  [gcc
version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release); g77 version
egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) (from FSF-g77 version
0.5.24-19981002)]

I am using the L-BFGS-B method to solve a minimization problem, and am setting
trace=1.  Lower and upper bounds are specified.  Thus, abbreviated code looks
like this:

L<-function(par)  {[DETAILS OF FUNCTION THAT RETURNS VALUE TO BE MINIMIZED]}
npar<-[Number of parameters]
xlo<-rep(0.01,npar) #similar behavior regardless of lower and upper bounds
xup<-rep(1.0,npar)
parinit<-0.01+0.5*runif(npar) #Similar behavior regardless of initial
parameters
ans<-optim(parinit,L,method="L-BFGS-B",lower=xlo,upper= 
xup,control=list(maxit=1000,trace=1))
print(ans)

The trace output clearly shows that the function is moving downhill and seems to
be converging.  A convergence code of 0 is returned, as is the message
"CONVERGENCE: REL_REDUCTION_OF_F <= FACTR*EPSMCH".  However, instead of
returning a function value and set of parameters corresponding to this solution,
optim() returns an absurdly high function value (1 or 2 orders of magnitude
higher than the minimized value shown by the trace output), and a parameter set
that seems to consist of a random array of the minimum and maximum bounds, with
a single parameter value different from this.  For example, with ten parameters,
each given a minimum and maximum of 0.01 and 1.0, the "solution" might consist
of something like (0.01, 0.01, 1.0, 0.45, 0.01, 1.0, 1.0, 1.0, 0.01, 0.01).

I have used the very same code with the same parameter initialization on R1.5.1
precompiled binaries running on Mac OSX 10.1.5, and I have encountered no such
problem.

I would be most grateful for any insight you might have into this problem. 
Thanks very much.