# of parameters in closed captures with heterogeneity

[mwegan]

I'm trying to generate a population estimate using 2 and 4 finite mixtures in the full closed captures with heterogeneity model type. However, when I run the models, the number of parameters listed in the results browser seems to be incorrect. For the general model when analyzing at 2 finite mixtures, the number of estimated parameters should be 32, but is listed as being 12. In fact all models have 12 parameters, according to MARK. I have gone through all the models and modified the number of parameters. This changes the final model averaged estimate due to the number of parameters affecting the AIC.

Questions: Why is Program MARK listing the number of parameters as 12 for all models? I've checked my work and the identity matrices are built correctly. MARK doesn't seem to have any problems discerning the number of parameters for other model types that I've used. Also, it seems to me to be absolutely logical and appropriate to be correcting the number of parameters for all models, but this does change the final population estimate by about 10%. Is there something that I'm not aware of that MARK is doing here that would make it inappropriate for me to be changing the number of parameters?

The data set I'm using is 8 time intervals. Since p8 is inestimable, I've fixed it for both mixtures. This means that MARK is actually estimating 30 parameters for the general model, but I estimated p for the final time step for each mixture. Does that mean that the number of parameters is 30 or 32?

Thanks for the help.

[TGrant7]

It takes very dense data to support 4 mixtures...

The procedure MARK uses to count parameters has something to do with "the trace of the G matrix", or something like that. So it's not simply counting the betas in your model. The reasons it uses that would have to be spoken to by someone else. One reason is that in some models, the number of parameters is not a whole number, and must be estimated by this trace. But if the numerical estimation for a parameter doesn't converge (you can generally tell when SEs are 0 or very very small), this procedure won't pick up that parameter. If it doesn't converge, that generally means your data is not dense enough to estimate that parameter, or at least get an MLE. Closed captures is the model type that has the worst time with this because the N ests can easily not converge with sparse data. So you always need to check the parameters MARK counted against how many their really are. In general, the number of parameters is the number of betas. The exceptions to this rule would have to be elaborated on by someone else. For example, I'm not sure off the top of my head if a non-identifiable situation like you have at the two end parameters there counts as 1 or 2 parameters. This is somewhat academic because if you have important p ests that aren't converging and MARK isn't counting them correctly, you should probably throw out that model because you don't have dense enough data to estimate that many parameters.

So you should correct your number of parameters in your models, and yes that will change your AIC values. And you should also throw out models that can't get any convergence on very many parameters.

Since so many parameters are not being estimated, and I assume they are all or mostly N's, you might want to consider whether you can estimate the heterogeneity parameters with your data. You would then go back and try some more simple models. And if those don't work, you can try Huggins data type which will always give N ests if the p's and c's converge, though the N's in Huggins are not MLEs. It sounds like you are trying to estimate too much from your data.

[cooch]

The procedure MARK uses to count parameters has something to do with "the trace of the G matrix", or something like that. So it's not simply counting the betas in your model. The reasons it uses that would have to be spoken to by someone else.

See - sidebar - starting on p. 28 of Chapter 4, for the basic details for parameter counting in general. Mixture models are more complex (as noted - I guess I should add something to 'the book'), and can also be multi-modal (in the likelihood). As such, it is worth routinely trying simulated annealing as the optimization method (the 'alternate optimization' you can specify in the run window), since it tends to converge on the global MLE (if convergence is possible at all).