Update: Equality by Lot is discussing this paper.
I have recently posted a working paper entitled Returning to the Cradle of Democracy: Citizen responses under election and sortition:
The hallmark of modern democracies is the competitive election. This institution is seen as the primary connection between leaders and the population. This has not always been the case. Sortition, the random selection of leaders from the population, served as the primary institution of democracy in ancient Athens. How would citizens in a modern democracy react to the use of sortition to select leaders? This study employs a survey experiment in which subjects read about a local development grant, overseen by either an elected or randomly selected committee. I find that sortition encourages more citizens to seek leadership positions, though other forms of participation remain unchanged. I also find that despite a stated preference for election, subjects see the two committees as equally capable and responsible, even when confronted with corrupt acts and closed door meetings.
The complete repository, including the code and data necessary to complete the paper, are available on GitHub.
Princeton University hosted the 2011 Polmeth conference, the annual meeting of political science methodology subsection of the APSA. This was my third Polmeth, and I found the talks to be the most approachable thus far (I think this says more about the presentations than my abilities). I only wish I could have attended the other talks during the split sessions, but one can only be in one room at a time (similarly, I could not visit many graduate student poster presentations while presenting my own).
My poster was titled “ACE in the Hole: A constructive critique of classical twins studies.” While there has been a steady stream of research linking genetic predispositions to political behavior, this research has not been well integrated into the broader political behavior literature. In part, I suspect this is because of the model most frequently employed in classical twin studies. The use of the so-called “ACE” model requires strong assumptions and does not directly engage the models and outcomes of other political science research. This poster attempts to layout a path where by the logic of the natural experiment embodied in twin studies can be used to simplify the analysis in a way that more directly engages traditional political science studies.
I’ve put my poster and the supporting materials online. I thank the UNL PolPhy Lab and the original data collectors for publishing the data I use in the poster.
For the last month or so, I have been using the test_that unit testing package for R (a quick note on names: both testthat and test_that are used in the documentation. The library, as available from CRAN has no underscore, so use install.packages('testthat') to get a copy). My free-time programming is always written a loosely TDD style, and I have rolled my own unit testing functions for R in the past, but they are not as polished as test_that. For examples of my test cases using test_that, see the RItools and optmatch repositories.
What attracted me to test_that was the autotesting functionality. As code is updated, tests are automatically re-run and failures are reported. If tests are updated, only the test files are re-run saving a little time. I find R CMD Check to be too slow for active development, and ad-hoc tests in the interactive session make me cringe. I can say that the autotest functionality in test_that is as good as any I have used for Ruby or Clojure (well, I’d still like Growl notifications, but it’s not a deal breaker). To get the full advantage, I suggest creating a Makefile in your project directory to handle starting up the autotest. Here is the Makefile from optmatch.
local-install:
rm -rf .local
mkdir .local
R CMD Install --library=.local .
autotest: local-install
R -q -e "library(optmatch, lib.loc = '.local')" \
-e "library(testthat)" \
-e "auto_test('./R', './inst/tests', 'summary')"
Then from the command line just type:
$ make autotest
To get the tests up and running.
While the package comes with functions for expressing many common expectations (e.g. expect_equal(a, b), I was hoping to start writing my own expectation functions, but have not had the time to dig into the internals to see how these are implemented. In most cases I end up using expect_true to evaluate a logical result, which works in most cases. There are two ways to write expectations: expect_equal(a, b) or expect_that(a, is_equal(b)). I tend to stick with the first as the second seems more verbose.
One last note: I had a little trouble integrating the test_that style tests in to R CMD Check. I found the devtools wiki to be helpful in this regard.