[R] Not nice behaviour of nlminb (windows 32 bit, version 2.11.1)

[Peter Ehlers]

Actually, it looks like any value other than 1.0
(and in (lower, upper)) for start will work.

   -Peter Ehlers

On 2010-07-09 14:45, Ravi Varadhan wrote:
> Setting abs.tol = 0 works!  This turns-off the absolute function convergence
> criterion.
>
>
>> nlminb( objective=function(x) x, start=1, lower=-2, upper=2,
> control=list(abs.tol=0))
> $par
> [1] -2
>
> $objective
> [1] -2
>
> $convergence
> [1] 0
>
> $message
> [1] "both X-convergence and relative convergence (5)"
>
> $iterations
> [1] 3
>
> $evaluations
> function gradient
>         3        3
>
>
> This is clearly a bug.
>
>
> Ravi.
>
> -----Original Message-----
> From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] On
> Behalf Of Ravi Varadhan
> Sent: Friday, July 09, 2010 4:42 PM
> To: 'Duncan Murdoch'; 'Matthew Killeya'
> Cc: r-help at r-project.org; bates at stat.wisc.edu
> Subject: Re: [R] Not nice behaviour of nlminb (windows 32 bit, version
> 2.11.1)
>
> Duncan, `nlminb' is not intended for non-negative functions only.  There is
> indeed something strange happening in the algorithm!
>
> start<- 1.0 # converges to wrong minimum
>
> startp<- 1.0 + .Machine$double.eps  # correct
>
> startm<- 1.0 - .Machine$double.eps  # correct
>
>> nlminb( objective=obj, start=start, lower=-2, upper=2)
> $par
> [1] 0
>
> $objective
> [1] 0
>
> $convergence
> [1] 0
>
> $message
> [1] "absolute function convergence (6)"
>
> $iterations
> [1] 1
>
> $evaluations
> function gradient
>         2        2
>
>>
>> nlminb( objective=obj, start=startp, lower=-2, upper=2)
> $par
> [1] -2
>
> $objective
> [1] -2
>
> $convergence
> [1] 0
>
> $message
> [1] "both X-convergence and relative convergence (5)"
>
> $iterations
> [1] 3
>
> $evaluations
> function gradient
>         3        3
>
>>
>> nlminb( objective=obj, start=startm, lower=-2, upper=2)
> $par
> [1] -2
>
> $objective
> [1] -2
>
> $convergence
> [1] 0
>
> $message
> [1] "both X-convergence and relative convergence (5)"
>
> $iterations
> [1] 3
>
> $evaluations
> function gradient
>         3        3
>
>
>> From the convergence message the `absolute function convergence' seems to
> be
> the culprit, although I do not understand why that stopping criterion is
> becoming effective, when the algorithm is started at x=1, but not at any
> other values.  The documentation in IPORT makes it clear that this criterion
> is effective only for functions where f(x*) = 0, where x* is a local
> minimum.  In this example, x=0 is not a local minimum for f(x), so that
> criterion should not apply.
>
>
> Ravi.
>
>
> -----Original Message-----
> From: r-help-bounces at r-project.org [mailto:r-help-bounces at r-project.org] On
> Behalf Of Duncan Murdoch
> Sent: Friday, July 09, 2010 3:45 PM
> To: Matthew Killeya
> Cc: r-help at r-project.org; bates at stat.wisc.edu
> Subject: Re: [R] Not nice behaviour of nlminb (windows 32 bit, version
> 2.11.1)
>
> On 09/07/2010 10:37 AM, Matthew Killeya wrote:
>>   nlminb( obj = function(x) x, start=1, lower=-Inf, upper=Inf )
>>
>
> If you read the PORT documentation carefully, you'll see that their
> convergence criteria are aimed at minimizing positive functions.  (They
> never state this explicitly, as far as I can see.)  So one stopping
> criterion is that |f(x)|<  abs.tol, and that's what it found for you.  I
> don't know if there's a way to turn this off.
>
> Doug or Deepayan, do you know if nlminb can be made to work on functions
> that go negative?
>
> Duncan Murdoch
>
>> $par
>> [1] 0
>>
>> $objective
>> [1] 0
>>
>> $convergence
>> [1] 0
>>
>> $message
>> [1] "absolute function convergence (6)"
>>
>> $iterations
>> [1] 1
>>
>> $evaluations
>> function gradient
>>         2        2
>>
>> 	[[alternative HTML version deleted]]
>>