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

[Michael Foote]

Dear Prof. Ripley:

*Many thanks for your prompt reply.
> 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.
*If the system is known to have unreliable compilers, that evidently
answers my question.
>
> The underlying code has only been altered since 1.5.1 in cosmetic ways.
>
> What did you expect us to do with this report?
>
*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

> On Wed, 14 May 2003 foote at 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 at 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
>