Message-ID: <Pine.LNX.4.44.0305140703290.13305-100000@gannet.stats>
Date: 2003-05-14T08:07:44Z
From: Brian Ripley
Subject: optim(method="L-BFGS-B"...) (PR#3000)
In-Reply-To: <200305140241.h4E2fo2b002951@pubhealth.ku.dk>
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