[EM] IRV vs Plurality (back to the pile count controversy)

[James Gilmour]

Kathy Dopp  > Sent: Friday, January 22, 2010 1:42 PM
> 
> OK James. As I said before, I agree with you that you were 
> giving the total number of profiles *if* voters were allowed 
> to rank all candidates, which they were not allowed to do in 
> Minneapolis or elsewhere in the US public elections if I am right.

In STV elections (STV, IRV, RCV) there should be NO restrictions of any kind on the number of rankings each voter may mark, up to
the limit of the number of candidates.  The voters should be completely free to mark as many or as few rankings as each wishes.


> Further, I think that Robert is correct, that one could 
> collapse the last N profiles into prior profiles if that is 
> the system that is used (allowing ranking all candidates), 
> although I do not think that gives any advantage, 
> practically, to the counting process and may even complicate it.

As I explained in my earlier post, whether or not you can do that depends on the version of the STV counting rules you have to use.


> My formula provides the more practical number of how many 
> profiles are allowed to be cast by voters and how many 
> profiles are needed if one wants to count the number of votes 
> cast for each profile and make IRV precinct-summable for an 
> actual election.

But if you do not report the complete preference profiles, down the last preference position (whether or not it is relevant to the
count), you reduce the transparency of the process.  The full ballot data should be published as soon as possible after the
election.  To provide complete information in the smallest size, the STV ballot data should be published as preference profiles,
i.e. COMPLETE preference profiles.  The BLT format is convenient for this.  The full ballot data from the 2007 STV-PR local
government elections in the City of Glasgow (Scotland) were published on the City Council's website as very soon after the count
closed on the day after polling.  They are still all there for inspection.


> Obviously Condorcet counting methods are much simpler to make 
> precinct-summable than IRV, requiring far fewer number of 
> sums per precinct as the number of candidates increases.

If you are going to do a manual sort of the ballots, then making three piles for each pair-wise comparison (A>B, B>A, neither
ranked) would involve less work than sorting to complete preference profiles.  But if you have sensible processing equipment that
task is trivial and the difference irrelevant.


> I think one thing that some election methods experts 
> sometimes fail to consider are the election administration 
> practicalities that are crucial to whether or not a method is 
> functionally practical to provide public oversight over.

The practicalities of election administration are extremely important and as a returning officer for some elections, I am well aware
of that.  But electoral administration must not be allowed to put artificial or "convenient" limitations on the democratic process.


> I am fully aware that it is voting system technology, costs, 
> and the increasing impracticality of manually auditing the 
> election if the full range of preference profiles is allowed, 
> if one is making an attempt to use paper ballots, that limits 
> the number of choices a voter may fill out.  I've studied 
> this issue for 7 years now.

We have absolutely no problems with any of this in our STV public elections in the UK.  We always take all our paper ballots to one
counting centre for each electoral district.  In Northern Ireland, the ballots are sorted and counted manually, under scrutiny.  In
Scotland in 2007 we used optical scanning equipment and OCR to produce the vote vector for each ballot and the vote vectors were
then consolidated into preference profiles for the STV counting program.  All the ballot handling was done under scrutiny.  There
are always some who are unhappy with the results (defeated candidates and their supporters!), but the process has not been
challenged.

James

No virus found in this outgoing message.
Checked by AVG - www.avg.com 
Version: 9.0.730 / Virus Database: 271.1.1/2637 - Release Date: 01/21/10 19:34:00