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

Ravi Varadhan rvaradhan at jhmi.edu
Mon Jul 12 03:05:30 CEST 2010


I guess it is ok, but then a warning should be added, when describing the `abs.tol' parameter in the help file to state that changing it may result in premature stopping when f(x*) = 0.  

Regards,
Ravi.

____________________________________________________________________

Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology
School of Medicine
Johns Hopkins University

Ph. (410) 502-2619
email: rvaradhan at jhmi.edu


----- Original Message -----
From: Duncan Murdoch <murdoch.duncan at gmail.com>
Date: Sunday, July 11, 2010 7:05 pm
Subject: Re: [R] Not nice behaviour of nlminb (windows 32 bit, version 2.11.1)
To: Ravi Varadhan <rvaradhan at jhmi.edu>
Cc: Matthew Killeya <matthewkilleya at googlemail.com>, Peter Ehlers <ehlers at ucalgary.ca>, r-help at r-project.org, bates at stat.wisc.edu


> On 11/07/2010 10:22 AM, Ravi Varadhan wrote:
>  >Hi,
>  >
>  >I am ok with setting abs.tol=0.   Here is an nlminb.patch that has 
> this.  There is just one line of code that has been added:  
>  >control$abs.tol <- 0
>  >
>  >I have commented where this change happens.
>  >
>  >I am sorry if I was not being clear.  I just wanted to have the 
> authors to also have a look at the source of the problem. 
>  
>  I've put in a different patch that sets the default value of abs.tol 
> to zero, rather than forcing it to zero in all calls.
>  
>  Duncan Murdoch
>  
>  >
>  >Regards,
>  >Ravi.
>  >
>  >____________________________________________________________________
>  >
>  >Ravi Varadhan, Ph.D.
>  >Assistant Professor,
>  >Division of Geriatric Medicine and Gerontology
>  >School of Medicine
>  >Johns Hopkins University
>  >
>  >Ph. (410) 502-2619
>  >email: rvaradhan at jhmi.edu
>  >
>  >
>  >----- Original Message -----
>  >From: Duncan Murdoch <murdoch.duncan at gmail.com>
>  >Date: Sunday, July 11, 2010 7:49 am
>  >Subject: Re: [R] Not nice behaviour of nlminb (windows 32 bit, 
> version 2.11.1)
>  >To: Matthew Killeya <matthewkilleya at googlemail.com>
>  >Cc: Ravi Varadhan <rvaradhan at jhmi.edu>, Peter Ehlers 
> <ehlers at ucalgary.ca>, r-help at r-project.org, bates at stat.wisc.edu
>  >
>  >
>  >>On 11/07/2010 5:00 AM, Matthew Killeya wrote:
>  >> >Thanks. Seems to me the easiest sensible fix might be to change the
>  >> >default abs.tol=0 in R and add a warning in the help files?
>  >> >    That was exactly my suggestion in the message to which Ravi 
> was replying, but he apparently has doubts.
>  >>  Duncan Murdoch
>  >> >Matt
>  >> >
>  >> >On 11 July 2010 01:41, Duncan Murdoch <murdoch.duncan at gmail.com> 
> wrote:
>  >> >
>  >> >   >>On 10/07/2010 7:32 PM, Ravi Varadhan wrote:
>  >> >>
>  >> >>     >>>Hi,
>  >> >>>
>  >> >>>The best solution would be to identify where the problem is in 
> the FORTRAN
>  >> >>>code and correct it.  However, this problem of premature 
> termination due to
>  >> >>>absolute function convergence is highly unlikely to occur in 
> practice.  As
>  >> >>>John Nash noted, this is going to be highly unlikely for multi-dimensional
>  >> >>>parameters (it is also unlikely for one-dimensional problem).  
> However,
>  >> >>>unless we understand the source of the problem, we cannot feel 
> comfortable
>  >> >>>in saying with absolute certainty that this will not occur for 
> n > 1.
>  >> >>> Therefore, I would suggest that either we fix the problem at 
> its source or
>  >> >>>we set abs.tol=0, since there is little harm in doing so.
>  >> >>>
>  >> >>>
>  >> >>>
>  >> >>>       >>Just for future reference:  that's not the kind of 
> answer that leads to
>  >> >>anything getting done.  So I'll leave it to the authors of nlminb.
>  >> >>
>  >> >>Duncan Murdoch
>  >> >>
>  >> >> Ravi.
>  >> >>     >>>____________________________________________________________________
>  >> >>>
>  >> >>>Ravi Varadhan, Ph.D.
>  >> >>>Assistant Professor,
>  >> >>>Division of Geriatric Medicine and Gerontology
>  >> >>>School of Medicine
>  >> >>>Johns Hopkins University
>  >> >>>
>  >> >>>Ph. (410) 502-2619
>  >> >>>email: rvaradhan at jhmi.edu
>  >> >>>
>  >> >>>
>  >> >>>----- Original Message -----
>  >> >>>From: Duncan Murdoch <murdoch.duncan at gmail.com>
>  >> >>>Date: Saturday, July 10, 2010 7:32 am
>  >> >>>Subject: Re: [R] Not nice behaviour of nlminb (windows 32 bit, 
> version
>  >> >>>2.11.1)
>  >> >>>To: Ravi Varadhan <rvaradhan at jhmi.edu>
>  >> >>>Cc: Matthew Killeya <matthewkilleya at googlemail.com>, Peter 
> Ehlers <
>  >> >>>ehlers at ucalgary.ca>, r-help at r-project.org, bates at stat.wisc.edu
>  >> >>>
>  >> >>>
>  >> >>>
>  >> >>>
>  >> >>>       >>>>Ravi Varadhan wrote:
>  >> >>>> >Hi,
>  >> >>>> >
>  >> >>>> >The absolute function stopping criterion is not meant for 
> any positive
>  >> >>>>objective function.  It is meant for functions whose minimum 
> is 0.  Here is
>  >> >>>>what David Gay's documentation from PORT says:
>  >> >>>> >
>  >> >>>> >"6 - absolute function convergence: |f (x)| <  V(AFCTOL) = 
> V(31). This
>  >> >>>>test is only of interest in
>  >> >>>> >problems where f (x) = 0 means a ‘‘perfect fit’’, such as nonlinear
>  >> >>>>least-squares problems."
>  >> >>>> >    Okay, I've taken a more careful look at the docs, and 
> they do say
>  >> >>>>that the return code 6 does not necessarily indicate 
> convergence:  "The
>  >> >>>>desirable return codes are 3, 4, 5, and sometimes 6".  So we 
> shouldn't by
>  >> >>>>default terminate on it, we should allow users to choose that 
> if they want
>  >> >>>>faster convergence to perfect fits.
>  >> >>>> Would changing the default for abs.tol to zero be a 
> reasonable solution?
>  >> >>>> Duncan Murdoch
>  >> >>>> >For example, let us try a positive objective function:
>  >> >>>> >
>  >> >>>> >   >>nlminb( obj = function(x) x^2 + 1, start=1, lower=-Inf, 
> upper=Inf,
>  >> >>>>control=list(trace=TRUE))      >  0:     2.0000000:  1.00000
>  >> >>>> >  1:     1.0000000:  0.00000
>  >> >>>> >  2:     1.0000000:  0.00000
>  >> >>>> >$par
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$objective
>  >> >>>> >[1] 1
>  >> >>>> >
>  >> >>>> >$convergence
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$message
>  >> >>>> >[1] "relative convergence (4)"
>  >> >>>> >
>  >> >>>> >$iterations
>  >> >>>> >[1] 2
>  >> >>>> >
>  >> >>>> >$evaluations
>  >> >>>> >function gradient        3        2  >
>  >> >>>> >Here the absolute function criterion does not kicks in.   >
>  >> >>>> >Now let us try a function whose minimum value is 0.
>  >> >>>> >
>  >> >>>> >   >>nlminb( obj = function(x) x^2, start=6, 
> grad=function(x) 2*x,
>  >> >>>>lower=-Inf, upper=Inf, control=list(trace=TRUE) )
>  >> >>>> >>     >  0:     36.000000:  6.00000
>  >> >>>> >  1:     4.0000000:  2.00000
>  >> >>>> >  2: 4.9303807e-32: 2.22045e-16
>  >> >>>> >$par
>  >> >>>> >[1] 2.220446e-16
>  >> >>>> >
>  >> >>>> >$objective
>  >> >>>> >[1] 4.930381e-32
>  >> >>>> >
>  >> >>>> >$convergence
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$message
>  >> >>>> >[1] "absolute function convergence (6)"
>  >> >>>> >
>  >> >>>> >$iterations
>  >> >>>> >[1] 2
>  >> >>>> >
>  >> >>>> >$evaluations
>  >> >>>> >function gradient        4        3  >We see that 
> convergence is
>  >> >>>>attained and that the stoppage is due to absolute function criterion.
>  >> >>>>         >>>>>Suppose, we now set abs.tol=0:
>  >> >>>>>           >>>> >
>  >> >>>> >   >>nlminb( obj = function(x) x^2, start=6, 
> grad=function(x) 2*x,
>  >> >>>>lower=-Inf, upper=Inf, control=list(trace=TRUE, abs.tol=0) )
>  >> >>>> >>     >  0:     36.000000:  6.00000
>  >> >>>> >  1:     4.0000000:  2.00000
>  >> >>>> >  2: 4.9303807e-32: 2.22045e-16
>  >> >>>> >  3: 2.4308653e-63: -4.93038e-32
>  >> >>>> >  4: 2.9962729e-95: -5.47382e-48
>  >> >>>> >  5:1.4772766e-126: 1.21543e-63
>  >> >>>> >  6:1.8208840e-158: 1.34940e-79
>  >> >>>> >  7:8.9776511e-190: -2.99627e-95
>  >> >>>> >  8:1.1065809e-221: -3.32653e-111
>  >> >>>> >  9:5.4558652e-253: 7.38638e-127
>  >> >>>> > 10:6.7248731e-285: 8.20053e-143
>  >> >>>> > 11:3.3156184e-316: -1.82088e-158
>  >> >>>> > 12:     0.0000000: -2.02159e-174
>  >> >>>> > 13:     0.0000000: -2.02159e-174
>  >> >>>> >$par
>  >> >>>> >[1] -2.021587e-174
>  >> >>>> >
>  >> >>>> >$objective
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$convergence
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$message
>  >> >>>> >[1] "X-convergence (3)"
>  >> >>>> >
>  >> >>>> >$iterations
>  >> >>>> >[1] 13
>  >> >>>> >
>  >> >>>> >$evaluations
>  >> >>>> >function gradient       15       13  >  Now, we see that it 
> takes a
>  >> >>>>while to stop, eventhough it is clear that convergence has 
> been attained
>  >> >>>>after 2 iterations.  This demonstrates the need for the 
> absolute function
>  >> >>>>criterion for obj functions whose minimum is exactly 0.  
> Although, there is
>  >> >>>>nothing wrong with setting abs.tol=0, except for some loss of 
> computational
>  >> >>>>efficiency.   >Now, let us get back to Matthew' example:
>  >> >>>> >
>  >> >>>> >   >>nlminb( obj = function(x) x, start=1, lower=-2, upper=2,
>  >> >>>>control=list(trace=TRUE))      >  0:     1.0000000:  1.00000
>  >> >>>> >  1:     0.0000000:  0.00000
>  >> >>>> >$par
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$objective
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$convergence
>  >> >>>> >[1] 0
>  >> >>>> >
>  >> >>>> >$message
>  >> >>>> >[1] "absolute function convergence (6)"
>  >> >>>> >
>  >> >>>> >$iterations
>  >> >>>> >[1] 1
>  >> >>>> >
>  >> >>>> >$evaluations
>  >> >>>> >function gradient        2        2  >   >>nlminb( obj = 
> function(x) x,
>  >> >>>>start=1, lower=-2, upper=2, control=list(trace=TRUE, 
> abs.tol=0))      >  0:
>  >> >>>>    1.0000000:  1.00000
>  >> >>>> >  1:     0.0000000:  0.00000
>  >> >>>> >  2:    -2.0000000: -2.00000
>  >> >>>> >  3:    -2.0000000: -2.00000
>  >> >>>> >$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  >
>  >> >>>> >Thus it is evident that setting abs.tol=0 is a reasonable, general
>  >> >>>>solution for functions whose minimum value is non-zero, 
> because it protects
>  >> >>>>against premature termination at iteration `n' whenever 
> |f(x_n)| < abs.tol.
>  >> >>>> The only limitation being that of loss of efficiency in 
> problems where
>  >> >>>>f(x*) = 0. where x* is the local minimum.
>  >> >>>> >
>  >> >>>> >Ravi.
>  >> >>>> >____________________________________________________________________
>  >> >>>> >
>  >> >>>> >Ravi Varadhan, Ph.D.
>  >> >>>> >Assistant Professor,
>  >> >>>> >Division of Geriatric Medicine and Gerontology
>  >> >>>> >School of Medicine
>  >> >>>> >Johns Hopkins University
>  >> >>>> >
>  >> >>>> >Ph. (410) 502-2619
>  >> >>>> >email: rvaradhan at jhmi.edu
>  >> >>>> >
>  >> >>>> >
>  >> >>>> >----- Original Message -----
>  >> >>>> >From: Duncan Murdoch <murdoch.duncan at gmail.com>
>  >> >>>> >Date: Friday, July 9, 2010 6:54 pm
>  >> >>>> >Subject: Re: [R] Not nice behaviour of nlminb (windows 32 
> bit, version
>  >> >>>>2.11.1)
>  >> >>>> >To: Matthew Killeya <matthewkilleya at googlemail.com>
>  >> >>>> >Cc: Peter Ehlers <ehlers at ucalgary.ca>, Ravi Varadhan <
>  >> >>>>rvaradhan at jhmi.edu>, r-help at r-project.org, bates at stat.wisc.edu
>  >> >>>> >
>  >> >>>> >
>  >> >>>> >   >>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 [
>  >> >>>> >> >>>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 [
>  >> >>>> >> >>>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