[EM] Cost of Manual Counting vs. Machine Counting

Jonathan Lundell jlundell at pobox.com
Fri May 25 12:51:53 PDT 2007


On May 25, 2007, at 10:40 AM, James Gilmour wrote:

>> Brian Olson> Sent: 25 May 2007 17:59
>>
>> I think this reinforces my position that the current best mix of
>> speed, reliability, trustworthiness and cost is to have people  
>> reading
>> ballots punching data into common desktop computers.
>>
>> Assuming the recognition is correct, missed kepresses should be  
>> relatively
>> rare, and there can be redundant counting for that and other reasons.
>
> I don't have any data to hand, but I remember from many years ago,  
> a senior statistician warning
> about the very significant error rate in any manual key-punching  
> operation when large amounts of
> data had to be input.  "Punch and verify", where every data form is  
> keyed in twice - the second time
> by a different operator, does reduce the number of errors that make  
> it into the data file, but of
> course, it doubles the time and cost.  (There have been lots of  
> studies on data-entry error rates,
> but I haven't searched for what is currently available on-line.)
>
> Also you must not underestimate the time the punching will take.  I  
> have just been looking at some
> of the Irish results now coming in, available on-line at  
> www.ireland.com.  One 5-member district I
> spotted had more than 61,000 valid ballots with 13 candidates.  
> That's a lot of key-strokes.  The
> Dáil Éireann has 166 members elected from 42 districts (3, 4 and 5- 
> member), but it is the number of
> candidates that determines the volume of data.

I've used double-data-entry for some small internal elections in the  
Green Party, and it's been fairly effective. The additional cost is  
mainly recruiting extra volunteers. The extra time is minimal, since  
the two entry teams can work in parallel (or you can publish  
provisional results and then do the second count).

Two details that complicate things a bit is that a) some counting  
rules are dependent on the order in which ballots are counted, so you  
have to make sure that the data entry proceeds in the same ballot  
entry in both cases, and b) if you find a discrepancy in the data  
entry, you need to be able to find the ballot in question, to resolve  
the discrepancy. In my small elections, I simply number the paper  
ballots as they're being entered the first time, and then pipeline  
them to the second data-entry group.

I've never done it for more than about a hundred ballots, though.




More information about the Election-Methods mailing list