RMark - time groups / covariates

posts related to the RMark library, which may not be of general interest to users of 'classic' MARK

RMark - time groups / covariates

Postby Karin » Mon Feb 23, 2009 7:09 am

Dear all,

For my analysis in RMark I want to merge some of the capture years (some kind of good, intermediate and bad years). I tried to do so by using "merge.desing.covariates". It worked nicely, but I was taken aback when I realised that I was creating (as the name of the function suggests) covariates and I think that the year-type should be a factor.
First I used “as.factor” to change the class type, but I’m not sure that this is the right way to do this.
So I took a closer look in the book. On page C 28 – 29 there was a description how to add new variables (dipper – flood example). I was puzzled to see that this created a numeric variable as well. Even more since the function “add.design.data”, which I could use for some other grouping of the time and which should simplify the process of merging time variables, produced a factor.

Right now I’m quite confused and uncertain how to proceed and I hope that someone can enlighten me on why those two methods produce different classes (and which should be used).

Sincerely,
Karin
Karin
 
Posts: 11
Joined: Wed Nov 19, 2008 5:13 am

covariate confusion

Postby jlaake » Mon Feb 23, 2009 11:01 am

Karin-

I think your confusion is partly due to my naming convention for the functions I created. I created add.design.data in the earliest version of RMark before I had considered some of the possibilities for design covariates. It is a very limited function because it only allows binning of adjacent time,age,cohort and only creates factor variables. The function merge.design.covariates allows much more flexibility but that flexibility is a little more demanding. Design covariates can be either factor variables (like time) or numeric variables (like effort or rainfall). Therefore it is up to the user to define those variables as they see fit. From the example, you are describing ("good", "bad","ugly") for time, you'll want a factor variable. If you have a dataframe that you created to merge with your design data, make sure that new field is a factor. You can always make it into a factor variable with the factor or as.factor function. If it is a factor variable in your dataframe then it should remain so after you have merged it into the design data. If that is not happening contact me offlist and we will work it out. Now with respect to the flood - dipper example, it is possible to treat a factor variable as a numeric variable by creating k-1 dummy variables (0/1) for a factor with k levels. With the flood example there are k=2 levels so you only need 1 variable with values 1 during flood years and 0 during non-flood years or the opposite if you chose. That approach is easy if k=2, but gets more difficiult and confusing to write formulas for k>2. You can think of dummy variables as pre-defined columns in the design matrix. Hope this helps. If you think the problem is with merge.design.covariates let me know.

--jeff
jlaake
 
Posts: 1479
Joined: Fri May 12, 2006 12:50 pm
Location: Escondido, CA

Postby Karin » Tue Feb 24, 2009 4:10 am

Dear Jeff,

Thanks for your fast and helpful reply. I changed the elements of the data frame into factors before I used the “merge.design.covariates”-function to merge them with the design data, and – as you predicted – they remained factors.

Karin
Karin
 
Posts: 11
Joined: Wed Nov 19, 2008 5:13 am


Return to RMark

Who is online

Users browsing this forum: No registered users and 2 guests

cron