[EM] IRV vs Plurality (Dave Ketchum)

[Abd ul-Rahman Lomax]

At 02:06 AM 1/16/2010, robert bristow-johnson wrote:
>On Jan 15, 2010, at 11:34 PM, Jonathan Lundell wrote:
>>On Jan 15, 2010, at 7:51 PM, Kathy Dopp wrote:
>>
>>>Imagine sending all your ballots nationwide to DC for manual counting
>>>to check the outcome of a Presidential election. We'll simply let the
>>>GW administration, for instance, count the results in his own IRV
>>>election!
>>
>>That's something of a non sequitur. Anyone with all the ballot
>>files (every state, for example, or anyone else) could do the count.
>
>and, in fact, it can be decentralized to the extent it is now.

It *can* be. Is it practical? Depends. Is it complicated? Yes. Is it 
vulnerable such that a small error somewhere compounds through the 
process, creating a necessity to recount elsewhere. Yes. Does this 
actually happen? Yes.

IRV creates many opportunities for close decisions, because each 
round involves finding the lowest vote-getter so that this candidate 
can be eliminated. This decision then affects the next round of 
counting, so if an error is found that flips one of these decision, 
*all subsequent counting* can be invalid.

This particular sensitivity is unique to sequential elimination, and 
it is why voting security experts are practically united in opposing 
IRV. Some of them are aware that there are better methods, even 
better in other ways, that don't have this problem.

>   each
>state could have their central place, and in turn, each county, each
>precinct.   the entire tree could be a public record on the internet
>that has links to child nodes or parent node.  with 3 credible
>candidates there are 9 piles to have to maintain.

Nine? Three candidates, to be able to report all the votes for usage 
in central processing, there are 15 piles, even if we strike, at the 
outset, all write-ins, provisionally, or other minor candidates with no hope:

A
B
C
AB
AC
BA
BC
CA
CB
ABC
ACB
BAC
BCA
CAB
CBA
spoiled

and, in fact, for the one or two rank ballots above, most 
jurisdictions would need to report write-ins or minor candidates at 
least in first rank, before elimination. So we'd add: exhausted, 
which might be sorted as to first rank on the exhausted ballot.

Total 17, actually, with only three candidates. And if there are more 
than three, how do we know which ones to count? We have to sort them 
all. Note that three candidates is the simplest IRV election 
requiring rounds, unless there is a two-candidate election with a lot 
of write-in votes.

It's common to lump all write-ins together, and write-ins are 
normally only reported in first rank with IRV (because they are 
irrelevant after elimination), but ... should it happen that all the 
write-in votes collectively are enough to shift an elimination 
sequence that might affect the overall results, then they would have 
to go back and break down the write-ins. Notice that this adds 
another set of piles. Is this a three-rank ballot, or is it four?

If an error was made somewhere else, they have to back up and resort 
to the pile before considering that erroneous report. Do you have any 
idea how much work this is? Basically, how would you do it? You would 
pretty much have to go back to the beginning, and resort, though 
you'd use batch elimination of all previously eliminated candidates. 
Sorting a ballot with all these votes on them is a tedious process, 
compared to just counting all the votes, and it's easy to make mistakes.

You will, I'd guess, argue that the third rank votes are irrelevant, 
since we are going to ignore all other possibilities. But in an 
election method, we can't ignore them, we must be able to distinguish 
between A>B>W and A>B>C, where the write-in is W. It's true that 
A>B>W gets classified into A>B after the initial elimination, but 
that counting must be done, creating, at least, a pile for Other as 
first preference. Or, say, Minor as first preference. And then, 
sometimes, if this single pile had enough votes in it in other 
jurisdictions, so that elimination can't be done in batch mode as 
mathematically irrelevant, you'd have to further sort...

It's a mess, Robert. They do it in Australia, by hand, so, sure, it 
can be done. They also, if I'm correct, don't allow write-ins. They 
do it centrally, so each voting district only maintains as many piles 
as candidates. For a long time, Australia didn't publish much of the 
election data, so we really don't know much about those elections. 
I'm not up on the latest....

>   each precinct
>sorts the ballots into one of 9 piles and counts it and puts the 9
>numbers up in this public place on the web.  everyone can check their
>own node to see that it isn't misreported.  i do not see why,
>physically, it would be more vulnerable to attack by the government
>in power that what is presently the case.  it's a factor of 9/2 more
>numbers to keep secure with that ranked ballot.

More. Simplifying assumptions have been made which make this look 
more practical.

>each state, each little government would be responsible to confirm
>their precinct totals on the map and everybody gets to look at it.
>what's particularly insecure about that?

The problem is that it's not as simple as Robert claims. But, yes, 
it's certainly possible to count IRV. But you can shift the results 
with an alteration in one single precinct, sometimes, in a way that 
ripples through the system and amplifies, so a small number of votes 
shift the rest of the results. Generally, voting security people like 
to use audits that select a sample of votes and look for errors, then 
they use statistical analysis to estimate the overall error in result 
probability. That's not nearly as easy with IRV, because IRV is a 
chaotic method, sensitive to a single vote error that ripples into 
shifting many votes. With many places where that single vote error can occur.

At least that's my understanding, I'd defer to Kathy on this!