Re: A 3-Step Audit Protocol w/ 99%confidence

From: charlie strauss <cems_at_earthlink_dot_net>
Date: Sat Jan 27 2007 - 00:06:47 CST

Kathy I sent that message to you privately, I'm not sure why it was essential to post it here. I apologize to the OVC for the perpetuation of this.

-----Original Message-----
>From: Kathy Dopp <kathy.dopp@gmail.com>
>Sent: Jan 27, 2007 12:45 AM
>To: Charlie Strauss <cems@earthlink.net>, Open Voting Consortium discussion list <ovc-discuss@listman.sonic.net>
>Subject: Re: [OVC-discuss] A 3-Step Audit Protocol w/ 99%confidence
>
>On 1/26/07, Charlie Strauss <cems@earthlink.net> wrote:
>>
> >
>> >>
>> >> I agree with arthur, this fudge factor is the achilles heel of the
>> >> recount strategy. The good news however is two fold.
>> >
>
>>
>> Kathy I think you need to re-read what I wrote. It clearly supports
>> the auditing scheme you have propose, so obviously you misunderstood
>> what I was saying.
>
>Hi Charlie,
>
>Thank you for continuing the conversation.
>
>Did I misunderstand that you said that there is a "fudge factor" in
>the audit methodology that is the achilles heel of the recount
>strategy? Or did someone else say that and I was confused?
>
>>
>> I suspect you are somehow thinking the term fudge factor is a
>> pejorative and that I am therefore opposing the auditing approach.
>>
>> I am not as your first question seems to think, suggesting
>> eliminating the fudge factor. I'm for keeping it.
>
>Well, it is impossible to eliminate the max vote miscount assumption
>to have any logical consistency in the calculations. It cannot be
>characterized as a fudge factor in the traditional use of that word.
>
>>
>> The point I was making is that there is a fudge factor because there
>> is no agreement yet on what level woul dbe considered "NOT
>> IMMEDIATELY NOTICEABLY SUSPICIOUS". If you re-read this you will
>> see I was pointing to some rather alarmingly high rates in Sarasota
>> FL that the judge did not consider suspcious enough.
>
>That is true Charlie. I'm sorry if I didn't recognize your points.
>However it is virtually irrelevant what value is picked for the
>assumed maximum vote shift as long as the same value is used to
>calculate what is suspicious and all suspicious vote counts are thrown
>into the audit sample along with the randomly selected ones, as I've
>mentioned in some of my footnotes and earlier emails on this subject.
>
>>
>> I thus took a moment to point out that raising this fudge factor
>> towards higher and higher levels to the point where any judge would
>> likely be moved to suspcision is going to lead to prohibitively high
>> sampling rates.
>
>Well, at most it can be moved up to 49.9% because beyond that is
>physically impossible, and at that level (of 49.9%) is beyond
>reasonable.
>
>>
>> Thus rather than throw the whole schema out, which is otherwise an
>> elegantly simple scheme, because we can't all agree on where to set
>
>Huh. It is not possible to "throw that whole schema out" if you want
>to have any logical consistency in the design of election audits.
>Please read this brief 3.5 page paper or my prior email again:
>
>http://electionarchive.org/ucvAnalysis/US/paper-audits/FourTierAudit/TieredElectionAudits.pdf
>
>> the fudge factor, I suggested we could essentially eliminate
>
>Charlie, again it is a gross mischaracterization to call it a "fudge factor".
>
>Again it is not important where one sets the max vote shift assumption
>as far as the efficacy of the audit to detect outcome-altering vote
>miscount, and the value you select would only effect the efficiency of
>the audit procedures.
>
>The value you select only effects how many vote counts are thrown into
>the audit sample due to being suspicious versus due to being randomly
>selected. Whatever value you select, you'll still have whatever
>desired probability you want for detecting outcome-altering vote
>miscount for the specific race.
>
>I've used 20% to be ultra conservative in the design of my tiered
>audits, since a 40% margin swing is huge and would be highly
>suspicious, but used 15% in my calculated audits since that is the
>high side of where the Brennan Center set the value in their
>appendices.
>
>> issue by having some stakeholder designated recount challenges
>> (jargon: TAR) on top of the random selection of recounts for
>> statistics. This will satisfy people better because when confronted
>> with a judge who still does not think that a 25% apparent vote shift
>
>A 25% vote shift from polls or whatever would mean a 50% margin shift
>which is HUGE, but the point is that if the audit assumes that all
>vote counts with more than a 15% partisan vote shift (30% partisan
>margin shift) are suspicious then you MUST throw all vote counts with
>more than that amount of partisan margin shift (of 30%) automatically
>into the manual audit sample. It is part of the process of auditing
>or the audit procedures are not logically coherent with the
>assumptions that the audits are based on.
>
>However research and development still needs doing to determine the
>best ways to calculate that, as I mentioned Ron Rivest asked me how I
>would suggest calculating it, but I am not planning to do any more
>unpaid work on elections. I've had it with being in the center of a
>circular firing squad of election integrity activists who either
>wrongly steal credit for my work or attack and malign it wrongly
>because they only want hand counted paper ballots without machines or
>audits. I'm trying to remove myself soon from the madhouse unless
>someone wants to fund me to finish the work.
>
>Kathy
>_______________________________________________
>OVC-discuss mailing list
>OVC-discuss@listman.sonic.net
>http://lists.sonic.net/mailman/listinfo/ovc-discuss

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue Jan 1 14:12:50 2008

This archive was generated by hypermail 2.1.8 : Tue Jan 01 2008 - 14:12:51 CST