www.phidot.org

Hi all,

I am trying to export my model list (a product of the mark.wrapper function) to MARK. In my model set, however, I have edited the design data by adding grouped of time intervals to determine the best way to model the temporal structure in survival (I am using known fate models). After running the function export.MARK, I noticed the AIC table had different results within MARK and then realized all of the export functions use the processed data and not the design data. So the edits I made to the design data are not in the process data. Is there a way to make it so grouped time intervals I made in the design data are also in the exported MARK file?

Thanks in advance,

Ben

Ben-

The design data is an RMark construct and it is only used to create the PIMS and DMs for MARK. The design data is not carried over to MARK. Your editing of the design data will be reflected in the PIM and DM structure of the model for MARK and that will be exported properly.

AIC is a function of the log-likelihood and the number of parameters. First look to see if the log-likelihood values are the same for the models that were run in MARK. They should be. My guess is that the difference will be with the parameter counts which will change the AIC value.

RMark assumes the DM is full rank and all parameters are identifiable which means the number of parameters is the number of columns in the DM. You can change that behavior by setting the adjust argument in mark.wrapper. Be aware that parameters that are at boundaries (e.g., phi=1) are not counted by MARK. Some of those parameters are estimable but are just at a boundary. Not counting them will tend to make you overfit models. Counting them when they are not identifiable (eg.,Phi(t)p(t)) is less egregious in my mind which is why I chose the default for RMark. You can set the number of parameters in an RMark model if you know some of the parameters are not identifiable. Others may disagree with my philosophy and you are welcome to set the adjust argument to get the default MARK behavior but just know what you are doing. I saw too many papers as a reviewer in which the novice user was overfitting and trying to explain nonsense parameters because MARK didn't count many of the parameters at boundaries. In my mind underfitting is better than overfitting.

regards --jeff

Hi Jeff,

Thanks for the reply, that was a very clear explanation. You were right about the parameters not being counted right.

Ben