Skip to content

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

3 messages · foote@geosci.uchicago.edu, Brian Ripley, Michael Foote

Original
foote@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.
Brian Ripley
# 
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:

            

      
      
      
    

        
Do try R 1.7.0 on your less ancient OS.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Michael Foote
    

    

      
      #
    

  


  

      
Dear Prof. Ripley:

*Many thanks for your prompt reply.

            

      
      
      
    

        
*If the system is known to have unreliable compilers, that evidently
answers my question.

            

      
      
      
    

        
*This was the first time I submitted a report, so I had no particular
expectations other than to determine whether some change might have been
introduced in 1.7.0 that could explain odd behavior relative to 1.5.
As you've indicated, this cannot be.  There's no obvious reason to think
this report would be of interest to other users.

Many thanks again for your help.  Untold numbers of us owe you and your
team a huge debt of gratitude for your brilliant work with R.

Yours truly,


Michael Foote
Professor of Paleontology
Dept. Geophysical Sciences
University of Chicago
Chicago, IL 60637 USA