This is a JavaTM application which does election counts according to the Irish Dáil counting rules. It needs Java version 5.0 or newer. If you don't have this version of the Java runtime, see below. The application also supports options for doing fractional counts (Gregory method).
The application is in the following file election.jar (right click and save-as). If your browser saves the file as election.zip, then you must rename the file to be "election.jar". To run it you can type the following command from a "Command prompt" window
java -jar election.jar
Note, this application is not particularly well tested. There is likely to be many bugs, but it is useful for looking at the pilot electronic elections in 2002.
Sample input files from the 2002 General Election in the Dublin North (4 seats), and Dublin West (3 seats) constituencies can be downloaded from this site. The files are contained in the two zip files at the bottom of the page. Also a file from the Meath constituency (5 seats) can be downloaded here. Select the MixedCsv.zip file
If those sites are no longer available then the data can be found in this zip file.
The application also allows you to do some interesting statistical experimentation with the data. What the pilot election data shows is that on average, voters typically express around 4 preferences per ballot, even though they are permitted to fill out the entire ballot which could contain 20 or more candidates. What is also interesting is that even fewer than 4 preferences end up being counted. On average, only around 2 preferences are looked at per ballot.
Note. Don't forget to unzip the .csv files from the compressed zip files.
One problem with publishing complete vote files is the potential for people to identify their own votes in the file. This obviously has implications for ballot secrecy, and further to the potential for coercion or vote selling. A simple selling scheme would be for a candidate to buy a #1 preference from a few hundred voters, and provide each voter with a unique combination of lower preference votes to use. By checking the vote file afterwards, the vote buyer, could make sure that each seller has voted the right way. There is a prety good chance that a combination of votes in a (say) 20 candidate election will be (nearly) unique. This problem would be practically impossible to detect, since unusual combinations of lower preferences (which are essentially sequences of random numbers) would be very difficult to distinguish from the background data (which itself looks fairly random).
This counting application provides a way to counter this problem by hiding the preferences which are not used in the count, and then writing out this modified file. The modified file would then be published instead of the original file. Of course, if only a subset file is published then extra steps need to be taken to audit this file. This issue is addressed in my proposed enhancement to the Nedap/Powervote system.
The application produces an output file called modified.csv which hides all of the preferences in the original input file, which were not used in the count. Each hidden preference is marked with a "*" asterisk character. This modified file can be used as input to the program, and it will always produce identical results. An interesting test, is to manually edit the file and hide any one (or more) non-hidden preference. Because of the deterministic nature of the counting algorithm, and the fact that the modified file contains the minimum set of preferences needed for the count, the newly hidden preference(s) will always be detected as an invalid vote file.
Statistically, what the modified csv file shows is that a very high percentage of preferences end up being hidden (around 80%) and this is particularly the case with ballots that express a high number of preferences. For example, in the Meath election, 4912 ballots expressed 10 or more preferences. When the unneeded preferences are removed, this number is reduced to only 5 (ballots with 10 or more preferences).
Note, there is still a theoretical possibility that a vote buyer could defeat even this modification. To do this in a feasible way, the seller would have to identify (or nominate) a list of candidates who have very little hope of getting elected. These candidates would be placed ahead of the buyer in each purchased vote, and therefore according to how STV works, could not be hidden in the modified vote file. Each purchased vote would be visible in its entirety. The difference here, is that this scheme would stick out like the proverbial sore-thumb in the modified vote file. Very simple analysis of the file would reveal that the candidate received a signficant number of votes with low preferences. The location of these voters could be identified (though not their identity) giving the Garda some scope for locating the sellers. The data would be strong circumstantial evidence, which could be used in a prosecution. Given the high probability of detection, and comparing this scheme with attacks that are already possible in the present system, makes it an acceptable risk in my opinion.
Please contact me if you have any questions about this.
Download Java by clicking button below.
Java and the Java Coffee Cup Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries