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

Duncan Murdoch murdoch.duncan at gmail.com
Sat Jul 10 00:54:24 CEST 2010


On 09/07/2010 6:09 PM, Matthew Killeya wrote:
> Yes clearly a bug... there are numerous variations ... problem seems to be
> for a linear function whenever the first function valuation is 1.
>   

Not at all.  You can get the same problem on a quadratic that happens to 
have a zero at an inconvenient place, e.g.

nlminb( obj = function(x) x^2-25, start=6, lower=-Inf, upper=Inf )

Ravi's workaround of setting the abs.tol to zero fixes this example, but 
I think it's pretty clear from the documentation that the whole thing 
was designed for positive objective functions, so I wouldn't count on 
his workaround solving all the problems.

Duncan Murdoch


> e.g. two more examples:
>  nlminb( obj = function(x) x+1, start=0, lower=-Inf, upper=Inf )
>  nlminb( obj = function(x) x+2, start=-1, lower=-Inf, upper=Inf )
>
> (I wasn't sure where best to report a bug, so emailed the help list)
>
> On 9 July 2010 22:10, Peter Ehlers <ehlers at ucalgary.ca> wrote:
>
>   
>> 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]]
>>>>
>>>>
>>>>         
>
>



More information about the R-help mailing list