formatting .INP files | approaches in Excel

[cooch]

Periodically, people ask for advice on how to 'take their encounter data' and re-format it into an encounter history .INP file. MARK has no 'built-in' data formatting tool, for a lot of good reasons. While it is hard to generalize recommendations on how to approach formatting encounter history files, what is increasingly clear is that many (most?) people store their 'data' in an Excel spreadsheet. While it is fairly straightforward (at least for experienced folks) to pull your data out of Excel with SAS or R, an manipulate it into an .INP file, it is perhaps even more efficient for most to generate the encounter histories directly within Excel.

To that end, Andrew Sterner (University of Central Florida) has generously sent me examples of how to use the 'pivot table' in Excel to do just that. Andrew provided 3 worked examples: a simple CJS live encounter example, a MS example, and a more complicated RD example.

I have added Andrews notes as an addendum to chapter 2 (the data formatting chapter).

http://www.phidot.org/software/mark/doc ... /chap2.pdf

The Excel spreadsheets referred to in the write up are in the markdata.zip file (at the bottom of the pulldown menu for individual book chapters).

I'd like to thank Andrew for his generous contribution. I'd also like to point out that he acknowledges there may be more elegant ways to use Excel for some of the functions/steps he describes. Please feel free to send them along. However, if you're adept at pulling data out of Excel, and manipulating the data into encounter histories in some other compute environment (SAS, R, Stata...), please resist the temptation to comment with something to the effect that 'It is easier to do this in...<insert environment here>'. Touting the merits of your preferred compute environment is the same sort of intellectual self-promotion as (oh say), 'I'm a Bayesian, and you're obvious silly - or not particularly clever - because you're not'.

[bacollier]

'I'm a Bayesian, and you're obvious silly - or not particularly clever - because you're not'.

Although, I suspect that it would be easy to put a prior on someone that is obviously silly...

[cooch]

'I'm a Bayesian, and you're obvious silly - or not particularly clever - because you're not'.

Although, I suspect that it would be easy to put a prior on someone that is obviously silly...

Sure, based on criterion that they use RMark under the premise it simplifies model building.

[claudiapenaloza]

'I'm a Bayesian, and you're obvious silly - or not particularly clever - because you're not'.

Although, I suspect that it would be easy to put a prior on someone that is obviously silly...

Sure, based on criterion that they use RMark under the premise it simplifies model building.

It simplifies modifying models that are too darn big to handle in MARK to begin with... have you ever tried to add time dependence in detection probabilities for within secondary and between primary sessions when you have say 3 secondary and 30+ primaries in a Multistate Robust Design with 4+ states?
Click, click, click, click, click, click, click.........

[cooch]

It simplifies modifying models that are too darn big to handle in MARK to begin with... have you ever tried to add time dependence in detection probabilities for within secondary and between primary sessions when you have say 3 secondary and 30+ primaries in a Multistate Robust Design with 4+ states?
Click, click, click, click, click, click, click.........

Whine...whine...whine. Apparently 'clicking' is too much physical effort for you. Suck it up, princess.

Actually, the probability of annoying/making errors is pretty much independent of which front end you use for MARK. Whatever works for you, works. RMark is really outstanding for the sorts of annoying 'scale' problems you're referring to. I simply reject the premise promulgated by some that it is any less prone to errors than using the 'classic' MARK interface.

[claudiapenaloza]

Suck it up, princess.

I do... much more readily now that I have the power of RMark (using all 10 fingers is so much better than using just one).

Actually, the probability of annoying/making errors is pretty much independent of which front end you use for MARK. Whatever works for you, works. RMark is really outstanding for the sorts of annoying 'scale' problems you're referring to. I simply reject the premise promulgated by some that it is any less prone to errors than using the 'classic' MARK interface.

Yep, because no matter which front end, you haven't switched the user.

[bacollier]

Whine...whine...whine. Apparently 'clicking' is too much physical effort for you. Suck it up, princess.

Rita Mae Brown from Sudden Death (I think): "Insanity is doing the same thing over and over again but expecting different results."

For my part (other than being what I think Evan has previously described as fanboy), I am just a guy trying to avoid carpal tunnel syndrome

[claudiapenaloza]

I am just a guy trying to avoid carpal tunnel syndrome

Tell me about it! When I first started structuring Bill Kendall's HUGE multistate models I had to switch to mousing with my left hand because I could no longer lift my right shoulder/arm. Death by clicking.

Besides, Evan is just resisting the inevitable: using R.

"Resistance is futile. You will be assimilated." The BoRg