Re: [R] Gradient function in OPTIMX
Ravi Varadhan
The gradient check in "optimx" checks if the user specified gradient (at starting parameters) is within roughly 1.e-05 * (1 + fval) of the numerically computed gradient. It is likely that you have correctly coded up the gradient, but still there can be significant differences b/w numerical and exact gradients. This can happen when the gradients are very large.
I would check this again separately as follows:
require(numDeriv)
mygrad <- gr.fy(theta0)
numgrad <- grad(x=theta0, func=gr.fy)
cbind(mygrad, numgrad)
all.equal(mygrad, numgrad)
Can you report these gradients to us?
In "optimx", we should probably change this into a "warning" rather than a "stop".
Ravi.
-------------------------------------------------------
Ravi Varadhan, Ph.D.
Assistant Professor,
Division of Geriatric Medicine and Gerontology School of Medicine Johns Hopkins University
Ph. (410) 502-2619
email: rvar...@jhmi.edu
______________________________________________
R-h...@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
John C Nash
is preceded by a check of the gradient at the starting values supplied using numDeriv.
That is, we evaluate the gradient with gr=(user's function for gradient) and then with
the grad() function from numDeriv. There are some tolerances used, and depending on your
function and its perversities (and most nonlinear functions do have some), there won't be
total agreement, so the message can get popped up.
Suggestion: Try evaluating the function and gradient at several sets of inputs along with
the numDeriv grad() equivalent and see if they are close enough in your own view. If not,
then possibly your gradient code is not quite right.
This suggestion is appropriate generally in building optimization problem codes, and is
part of the optimgui package of Yixuan Qui built in the recent Google Summer of Code effort.
John Nash
On 08/30/2011 06:00 AM, r-help-...@r-project.org wrote:
> Message: 10
> Date: Mon, 29 Aug 2011 02:10:36 -0700 (PDT)
> From: Kathie <kathryn....@gmail.com>
> To: r-h...@r-project.org
> Subject: [R] gradient function in OPTIMX
> Message-ID: <1314609036951...@n4.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Dear R users
>
>
> When I use OPTIM with BFGS, I've got a significant result without an error
> message. However, when I use OPTIMX with BFGS( or spg), I've got the
> following an error message.
>
> ----------------------------------------------------------------------------------------------------
>
>> > optimx(par=theta0, fn=obj.fy, gr=gr.fy, method="BFGS",
>> > control=list(maxit=10000))
> Error: Gradient function might be wrong - check it!
>
> ----------------------------------------------------------------------------------------------------
>
> I checked and checked my gradient function line by line. I could not find
> anything wrong.
>
> Is it a bug or something? I prefer OPTIMX, so I'd like to know why.
>
> Thanks a lot in advance
>
> Regards,
>
> Kathryn Lord
>
> --
> View this message in context: http://r.789695.n4.nabble.com/gradient-function-in-OPTIMX-tp3775791p3775791.html
> Sent from the R help mailing list archive at Nabble.com.
>
>
>
> ------------------------------
Kamil Bartoń
The 'adjusted CI' (based on the 'adjusted se estimator' as in section 4.3.3 of Burnham & Anderson
2002) cannot be calculated for 'lmer' model because it does not give df's for the coefficients.
kamil
Dnia 2011-08-30 12:00, r-help-...@r-project.org pisze:
> Message: 42
> Date: Mon, 29 Aug 2011 08:28:22 -0700 (PDT)
> From: Marcos Lima<robalin...@googlemail.com>
> To:r-h...@r-project.org
> Subject: [R] MuMIn Problem getting adjusted Confidence intervals
> Message-ID:<1314631702645...@n4.nabble.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hello R users
>
> I'm using MuMIn but for some reason I'm not getting the adjusted confidence
> interval and uncoditional SE whe I use model.avg().
>
> I took into consideration the steps provided by Grueber et al (2011)
> Multimodel inference in ecology and evolution: challenges and solutions in
> JEB.
>
> I created a global model to see if malaria prevalence (binomial
> distribution) is related to any life history traits of 14 different birds
> species, while controling for Family and genus in a GLMM:
>
> global.model.Para<-lmer(cbind(Parahaemoproteus,FailPh)~factor(SS)+factor(NT)+NH+W+IT+factor(MS)+(1|Family/Genus),family=binomial,data=malaria)
>
> I than standardize the input variables using the function standardize form
> the arm package:
>
> stdz.model.Para<-standardize(global.model.Para,standardize.y=FALSE)
>
> But I get this message:
> Warning messages lost:
> In is.na(thedata):
> is.na() aplied to an object different from list or vector of type "Null"
>
> I then proceed to use the dredge fucntion:
> model.set.Para<-dredge(stdz.model.Para)
> <...>
> top.models.Para<-get.models(model.set.Para,subset=delta<=7)
> top.models
>
> But when I do the model average I do not seem to be getting the variance or
> Uncoditional SE and I'm guessing that the Confidence interval are no
> conditional either:
>
> model.avg(top.models.Para,method="NA")
>
> <...>
>
> Averaged model parameters:
> Coefficient SE Lower CI Upper CI
> (Intercept) -4.75 1.410 -7.510 -1.9900
> factor(MS)1 -1.54 0.809 -3.120 0.0471
> factor(NT)1 2.28 1.310 -0.286 4.8500
> factor(SS)1 3.30 0.968 1.400 5.2000
> z.IT -2.79 2.230 -7.160 1.5800
> z.NH 2.28 1.660 -0.968 5.5300
> z.W -1.74 1.490 -4.650 1.1800
> Confidence intervals are unadjusted
>
> Relative variable importance:
> factor(SS) factor(MS) z.NH z.IT z.W factor(NT)
> 0.82 0.33 0.32 0.20 0.07 0.01
>
> Does anyone know what I might be doing wrong?
>
> thanks for the help
>
> Marcos
Ben Bolker
>
> Hi Marcos,
>
> The 'adjusted CI' (based on the 'adjusted se estimator'
> as in section 4.3.3 of Burnham & Anderson
> 2002) cannot be calculated for 'lmer' model because it
> does not give df's for the coefficients.
>
> kamil
If you're willing to use MASS::glmmPQL instead (which gives
df's, because it is based on lme which does give df's) it
might work.
KKulma
I seem to be having a similar problem, but with glmer models. Here,
model.avg() doesn't return anything but coefficient values:
fl19<-glmer( corrFLEDGE ~ INFECTION * rsLD * bin.age + (1 | year) + (1 |
RINGNO),data=corrmalaria,family=poisson)
fledglings<-dredge(fl19)
top.fledglings <- get.models(fledglings, subset = delta < 5)
model.avg(top.fledglings)
Call:
model.avg.default(object = top.fledglings)
Component models:
‘236’ ‘12346’ ‘1236’ ‘123456’ ‘12356’ ‘1234567’
Coefficients:
(Intercept) INFECTIONUninf rsLD
1.49862573 0.04925663
0.01954281
INFECTIONUninf:rsLD bin.agejuv
bin.agejuv:INFECTIONUninf
-0.03728832 0.10506037
-0.19701898
bin.agejuv:rsLD bin.agejuv:INFECTIONUninf:rsLD
-0.01630556 0.02379715
Any ideas how I could solve that?
thanks for your help!
best,
Kasia
--
View this message in context: http://r.789695.n4.nabble.com/Re-MuMIn-Problem-getting-adjusted-Confidence-intervals-tp3793448p4634625.html
Sent from the R help mailing list archive at Nabble.com.
______________________________________________
Kamil Bartoń
pozdrowienia,
kamil
Dnia 2012-06-28 12:00, KKulma<katarzy...@ebc.uu.se> pisze:
> Message: 60
> From: KKulma<katarzy...@ebc.uu.se>
> To:r-h...@r-project.org
> Subject: Re: [R] MuMIn Problem getting adjusted Confidence intervals
>
> I seem to be having a similar problem, but with glmer models. Here,
> model.avg() doesn't return anything but coefficient values:
>
> fl19<-glmer( corrFLEDGE ~ INFECTION * rsLD * bin.age + (1 | year) + (1 |
> RINGNO),data=corrmalaria,family=poisson)
>
> fledglings<-dredge(fl19)
>
> top.fledglings<- get.models(fledglings, subset = delta< 5)
>
> model.avg(top.fledglings)
>
> Call:
> model.avg.default(object = top.fledglings)
>
> Component models:
> Coefficients:
> (Intercept) INFECTIONUninf rsLD
> 1.49862573 0.04925663
> 0.01954281
>
>
>
> INFECTIONUninf:rsLD bin.agejuv
> bin.agejuv:INFECTIONUninf
> -0.03728832 0.10506037
> -0.19701898
>
>
> bin.agejuv:rsLD bin.agejuv:INFECTIONUninf:rsLD
> -0.01630556 0.02379715
>
> Any ideas how I could solve that?
>
> thanks for your help!
> best,
> Kasia
>
John C Nash
1) I am on record several times that CG was the LEAST SUCCESSFUL of the codes I put in my
1979 book and which is CG in optim().
2) Rcgmin is better (I implemented this, but the method is Yuan/Dai), and there may be
other CG codes that can squeeze a bit more performance from this family of codes.
3) CG without analytic derivatives is fish and chips with either no fish or no chips or
just the greasy paper.
4) CG is intended for large n problems, 300 or 3000 rather than 3.
JN
On 06/28/2012 06:00 AM, r-help-...@r-project.org wrote:
> Message: 102
> Date: Thu, 28 Jun 2012 09:54:24 +0000
> From: <nat...@orchidpharma.com>
> To: <R-h...@r-project.org>
> Subject: [R] Strating value problem for CG in optim()
> Message-ID:
> <D53C394DF9CD604EAAB6...@SLREXCH.ORCHIDPHARMA.COM>
> Content-Type: text/plain; charset="us-ascii"
>
>
> Dear list-members,
>
> I have done optimization of 3 parameters by maximum likelihood method using conjugate gradient as optimizer. Since I have the reported value of the parameters from an article, I can validate the result of the optimized parameters. The problem is that optimizer converges to the desirable value. (as reported in the article) only for a certain starting value.
>
> If the staring value of the parameters are like (2,1,1) then the value of parameters the function converges is
> $par
> [1] -0.4169408 -0.2800828 2.9614670
>
> And the value is close to the value of article reported in the article
> Vs = 0.4861 ; Vn = 0.1478 and m is some positive value (no value mentioned in the article)
>
> And If I fine tune the starting value from (2,1,1) to (1.949,1.13,1) then I get the value of the parameters very close to the one reported.
>
> $par
> [1] -0.4700892 -0.1428245 2.9614670
>
> Now the question is how I can find the starting values for the test experiment for which I am going to implement this optimization procedure.
> Is there any function to be wrapped with optim() to find the right starting value.
>
>
>
> Regards,
> B.Nataraj