huge beta SEs with DM, not PIMs - same real estimates

questions concerning analysis/theory using program MARK

huge beta SEs with DM, not PIMs - same real estimates

Postby gofish » Mon Jun 18, 2007 3:17 pm

I have a data set with 7 occasions and 2 groups for a recpatures only model. If I modify the PIMs to get a phi(t), p(t) model all appears well. However, if I use the design matrix to constrain the PIMs for the same model, the betas are in the ballpark (but different than the PIM model), and their SEs are about 175. The real paramater estimates from the two methods are identical - what gives? I tried the current version of MARK and one from last June with the same result. I selected the logit link when I ran the PIM model, so I believe the link function was the same for the two methods. How can the betas be different and the real estimates be the same if the link function is the same? The design matrix is below if interested....

thanks,

john beeman

INPUT --- 1 1 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 1 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 1 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 1 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 1 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 1 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 1 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 1 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 1 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 1 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 0 0 0 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 1 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 1 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 1 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 1 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 1;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 1 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 1 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 1 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 1 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 1;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 0;
gofish
 
Posts: 3
Joined: Mon Jun 12, 2006 3:57 pm
Location: Cook, Washington

huge beta SEs with DM, not PIMs - same real estimates

Postby gwhite » Mon Jun 18, 2007 3:37 pm

John:
What you see is actually common in MARK because you have run a fully time-specific model with the last phi and p confounded. Therefore, the beta variance-covaraince matrix is singular. The result is that the beta SE appear to be garbage. In fact, the singular-value decompostion of this matrix leads to valid SE for the real parameters.
One "trick" is to recode the design matrix so that the confounded parameters (i.e., the last phi and p) are not coded to be their respective intercepts. So, if you were to code the following design matrix, you would get more reasonable SE on the beta estimates. In this matrix, the intercepts correspond to the first phi and first p, instead of to the last phi and last p that are confounded. Beta6 and Beta12 now correspond to the confounded parameters.

INPUT --- 1 0 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 1 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 1 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 1 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 1 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 1 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 1 0 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 1 0 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 1 0 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 1 0 0 0 0 0 0 0;
INPUT --- 1 0 0 0 0 1 0 0 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 1 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 1 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 1 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 1 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 1;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 1 0 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 1 0 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 1 0 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 1 0;
INPUT --- 0 0 0 0 0 0 1 0 0 0 0 1;

Gary
gwhite
 
Posts: 340
Joined: Fri May 16, 2003 9:05 am

Re: huge beta SEs with DM, not PIMs - same real estimates

Postby cooch » Mon Jun 18, 2007 4:00 pm

gwhite wrote:John:
What you see is actually common in MARK because you have run a fully time-specific model with the last phi and p confounded. Therefore, the beta variance-covaraince matrix is singular. The result is that the beta SE appear to be garbage. In fact, the singular-value decompostion of this matrix leads to valid SE for the real parameters.
One "trick" is to recode the design matrix so that the confounded parameters (i.e., the last phi and p) are not coded to be their respective intercepts. So, if you were to code the following design matrix, you would get more reasonable SE on the beta estimates. In this matrix, the intercepts correspond to the first phi and first p, instead of to the last phi and last p that are confounded. Beta6 and Beta12 now correspond to the confounded parameters.


Gary


This basic approach is described in 'the book' in Chapter 6 (the big linear models chapter). In fact, there is a strong reason to argue that MARK shouldn't default to making the final estimates in a time-dependent model the reference cell in the linear model (which uses reference cell or offset coding by default), but...

Here is an example of the difference it makes - the following are the estimates and associated SE for the full Dipper data (both sexes - this file is distributed with MARK), for model phi(t)p(t), using the default coding:

Code: Select all
 Parameter                     Beta         Standard Error
 -------------------------  --------------  --------------
    1:Phi Int                1.1195064       303.1981097 
    2:Phi t1                -0.1840472       303.1997194 
    3:Phi t2                -1.3823256       303.1981967 
    4:Phi t3                -1.2068799       303.1982185 
    5:Phi t4                -0.6039090       303.1981967 
    6:Phi t5                -0.7201485       303.1981097 
    7:p Int                  0.8655834       251.9396036 
    8:p t1                  -0.0363022       251.9411263 
    9:p t2                   1.6193241       251.9420725 
   10:p t3                   1.4857920       251.9409631 
   11:p t4                   1.3404411       251.9404628 
   12:p t5                   1.7587913       251.9401691 


Note the SE's are nonsensical. If you look at the 'details' in the full output for this model, you'll see in various places the singularity problem Gary refers to.

Now, if we re-code the DM, and make the first interval/occasion the reference cell, then the estimates are much more reasonable:

Code: Select all
 Parameter                     Beta         Standard Error
 -------------------------  --------------  --------------
    1:Phi Int                0.9354594       0.8358884   
    2:Phi t1                -1.1982787       0.9469900   
    3:Phi t2                -1.0228330       0.8754707   
    4:Phi t3                -0.4198625       0.8800756   
    5:Phi t4                -0.5361013       0.8735443   
    6:Phi t5                 0.2481194       213.8003960 
    7:p Int                  0.8292804       0.8524349   
    8:p t1                   1.6556257       1.4045775   
    9:p t2                   1.5220955       1.1669630   
   10:p t3                   1.3767439       1.0751288   
   11:p t4                   1.7950917       1.1625714   
   12:p t5                  -0.0147426       163.2849561 


In general, for full time-dependent models (or, in fact, any models with strongly confounded parameters), it is *not* a good idea to make such confounded parameters the reference in the DM.
cooch
 
Posts: 1654
Joined: Thu May 15, 2003 4:11 pm
Location: Cornell University

Postby gofish » Mon Jun 18, 2007 5:22 pm

Thanks guys - that workaround worked of course. I have other data sets (a bit larger) with the same model framework and did not see the problem, which is why it seemed so confusing this time around. Is the problem somewhat data set specific? I used individual covariates and examined the betas, etc. in my other analyses and was worried they were in error - a quick check with the revised DM resulted in the same betas and SEs for the covariates as the original model - I see why now.

john
gofish
 
Posts: 3
Joined: Mon Jun 12, 2006 3:57 pm
Location: Cook, Washington

Postby gofish » Mon Jun 18, 2007 5:29 pm

Just checked my other analyses - the models were phi(t) p(g + t), so not the same as the current phi(t)p(t) with the problems. I
john
gofish
 
Posts: 3
Joined: Mon Jun 12, 2006 3:57 pm
Location: Cook, Washington

Postby cooch » Mon Jun 18, 2007 5:58 pm

gofish wrote:Thanks guys - that workaround worked of course. I have other data sets (a bit larger) with the same model framework and did not see the problem, which is why it seemed so confusing this time around. Is the problem somewhat data set specific?
john


Yes - more or less problem-specific. In general, though, the admonition made in earlier relies (about not using the final time step as the reference cell whenever there is a confounded parameter involved) stands.
cooch
 
Posts: 1654
Joined: Thu May 15, 2003 4:11 pm
Location: Cornell University


Return to analysis help

Who is online

Users browsing this forum: No registered users and 2 guests