R devel - May 2003 - optim(method="L-BFGS-B"...) (PR#3000)

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.

There is nothing here we can reproduce: that is a very old system with 
known unreliable compilers, and there is no example which can be checked 
on a current system.

The underlying code has only been altered since 1.5.1 in cosmetic ways.

What did you expect us to do with this report?

On Wed, 14 May 2003 foote@geosci.uchicago.edu wrote:
> 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.
Do try R 1.7.0 on your less ancient OS.

-- 
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 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595