Voting Project Needs Python People

[Andrew Dalke]

Alan Dechert:
> Let me try to clarify what I'm after.  The paper record should always
match
> the electronic record.  So the allowable defects is zero.  If there is a
> mismatch found in the sample, we don't publish the electronic tally: we
take
> all the paper ballots and check them.

You cannot get zero allowable defects.  As best, you can get the likelihood
of allowable defects to be less than one.

For example, there will be hardware problems.  Parts break down,
the machines are exposed to large temperature swings, the scanners
might be confused by a swarm of bugs, pages can stick together because
of the humidity, ballots can be left in the trunk of a car 'by accident'
(happened here in NM for the 2000 election).

You can spend more money to reduce the likelihood of error.  You
can develop higher quality scanners and you can hire more people to
review the ballots.  But even if you scan the ballots twice by machine
(each with different mechanisms) and another time by human, with
descrepancies broken by another inspection, you still have the chance
that all of those steps fail.  A low chance, but still a chance.

Even in the method you propose (machine scanning with a human
double checking a sample), suppose the human doing the sampling
doesn't notice the machine's result is wrong?  (Boredom is insidious.)

> So, if by the preliminary electronic tally a candidate won a race by 1
> percent, I want to know how many ballots we have to check (random sample)
to
> be certain that the result predicted is true.

Right.  In this case you shouldn't mind errors - you just want to be 99.99%
sure that there's less than a, say, 0.05% error rate.

> When I put one million into this Confidence Level Calculator, and
Acceptable
> Quality Level of .01, a sample of 10,000 shows a confidence level of "1."
A
> sample of 2000 give C.L of 0.999999998  Presumably, "1" is really
> .9999999999+ more 9s.  Can we get more decimal places?

At most 17 9s and possibly less.  Python's 'str' rounds to 1 at 13 places,
while its 'repr' (which uses a more precise method) takes 17.

>>> 0.99999999999999
0.99999999999999001
>>> 0.999999999999999
0.999999999999999
>>> 0.9999999999999999
0.99999999999999989
>>> 0.99999999999999999
1.0
>>>
>>> str(0.999999999999)
'0.999999999999'
>>> str(0.9999999999999)
'1.0'
>>>

More likely it depends on whoever wrote the calculator you're using.

If you want 100% certainty (and not 99.9999+%) then you'll end up
having to verify everything, which means you are no longer sampling
the results.  But the reason to use sampling is because the verification
step is too expensive to apply it to everything, and because if you
*did* test everything then you'll still need a sample to verify your
verifiers.  (Whether they be human or machine.)

Do you have an estimate for the failure rate in the verifiers?

> So I guess the Lot Fraction Defective is analgous to the predicted victory
> margin.  Is that right?

I'm the wrong one for that - can you go over to the nearest statistics
department and ask for assistance?

                    Andrew
                    dalke at dalkescientific.com