[Election-Methods] KPFK LSB election

[James Gilmour]

Jonathan Lundell  >Sent: 30 December 2007 21:15
> > Jonathan Lundell  > Sent: 30 December 2007 19:22
> >> I've posted the tally sheet (I don't know whether it's official; I got
> >> it informally from one of the candidates), temporarily, for anyone  
> >> who might be interested:
> >>
> >> http://homepage.mac.com/jlundell/filechute/KPFK%20hand%20count.zip

> > On Dec 30, 2007, at 12:53 PM, James Gilmour wrote:
> > Jonathan
> > This is very interesting and it would be very useful to see the
> > Election Rules they used.  I don't think these are BC-like rules,
> > i.e. applying the Weighted Inclusive Gregory Method (WIGM) of  
> > transferring surpluses.  I suspect the rules are more like the STV
> > rules for the Australian Federal Senate elections, i.e. Inclusive  
> > Gregory Method (IGM).
> >
> > I suggest that, because when Grace Aaron's surplus is transferred
> > (Round 21), they show only one transfer value (cell BK7 =
> > 0.04476852).  But Grace Aaron then held ballot papers of two  
> > different values, namely 1.00 (her own first preferences and all the
> > first preferences transferred to her from excluded candidates) and  
> > 25.5 ballots @ 0.213867(etc) transferred from the surplus of
> > W01-Ahjamu Makalani.  If they had been using BC-like rules, they  
> > would have had to apply two different transfer values.  Instead,
> > they have averaged, the way the Australians do (and that is  
> > fundamentally flawed).
> >
> > They also seem to have used arithmetic of indeterminate precision -
> > there is no truncation to a stated precision.  Some results are
> > shown to 14 decimal places, others to 16 decimal places.  The  
> > differencing values are shown to 29 decimal places.  I don't know how
> > they did these calculations because my version of Excel (Excel 2002)  
> > cuts out at 15 decimal places.  They start with 2246 votes, but
> > at Round 5 they have gained nearly one whole extra vote and then  
> > they progressively lose votes.  If the calculations are done
> > correctly and consistently, the vote total at the completion of each  
> > Round should always be exactly 2246.
> >
> > Although I can follow the calculations, it seems illogical to me to
> > have put the numbers of transferred votes in a column before the
> > numbers of ballot papers from which the vote values were calculated.

> Yes, that's confusing.
> 
> And you're clearly right about this not being BC, which would, now  
> that I think about it, not be amenable to calculation with such a  
> simple spreadsheet.

Jonathan    
I would not recommend doing a large BC-STV count (WIGM) by hand, but it can be recorded quite simply on a spreadsheet.  Instead of
having only one column of transfer values, you have as many columns as you have differently valued ballot papers in that transfer
(ideally two columns for each, first showing the numbers of ballot papers, second showing the value of the votes so transferred).
That could be followed by a column of total votes transferred and then the cumulative vote for that stage (round).  It is not on a
spreadsheet, but you will see the two parts of this calculation if you look at the tables on page 5 of:        
  http://www.votescotland.com/stv/files/STV-WIGMCountDetailedDescriptionVS19Apr07.pdf

An extended version of this description is available at:       
 http://www.jamesgilmour.org.uk/STV-WIGM-Count-Description-JG-Preprint-25May07.pdf    
(access to the published version is restricted by publisher's copyright).


> There are some interesting transfers. U16 for example:  
> =1+1/4/5+1/8/7+1/9/8+1/8/7

I find it difficult to tell how these come about  -  I suspect it is something to do with the fractional first and subsequent
preferences arsing from allowing equal preferences.  As all preferences in STV-PR as contingency choices ("my first choice
candidate", "my second choice candidate", etc), it is nonsense to me to allow "equal preferences".  But if you want to allow equal
preferences in STV -PR you must implement that feature properly as it can create all sorts of complications for other parts of the
calculations.

The Australians avoid some complications in their (invalid) IGM system, by crediting candidates only with integer numbers of votes,
the fractions "lost" by such truncation being recorded separately. (Australia does not use "equal preferences".)


 
> I'd be curious to see just how repeatable a recount would be.

This count is not repeatable as the precision of the calculations has not (apparently) been defined, and (on the assumption it has
all been done on an Excel spreadsheet) has been allowed to use arithmetic of indeterminate length.  You must define the precision,
and that precision must be within the capacity of all the systems you expect to use, so that any program that accurately implements
the counting rules, written in any programming language, compiled by any complier, and run on any hardware under any operating
system will always produce identical results from the same input.  For the Scottish WIGM elections in May 2007 (the first in the
world), the precision was set at five decimal places on the pragmatic basis that using more than five decimal places made no
difference to the results in a large number of tests run on the ballots in the STV dataset.

The repeatability of the manual sorting and counting of the ballot papers would depend primarily on how well the logistics were
arranged.  Of course, allowing "equal preferences" makes that VERY much more complicated than it would be in a standard STV count.
Here, there were only 2246 ballot papers which is not very many at all for a hand count, though the WIGM rules would take longer to
process than the Gregory Method rules.


> An  
> example like this illustrates just how difficult it can be to audit a  
> hand count of a large STV election.

I don't know what you mean by "audit".  In STV-PR public elections in Northern Ireland (manual counts with Gregory Method rules),
the standard practice (following ERS "best practice") is to sort the ballot papers, check the sorting, count the ballot papers and
then check the counting, all under the eyes of the candidates and their agents and scrutineers.  If the papers are correctly sorted
and correctly counted, there is nothing else to audit, because the calculations are trivial (though maybe tedious) and can be
checked very easily.  Under NI Election Rules, if any candidate challenges the outcome of any stage (round) of the count, he/she can
request a re-count only of the contested stage.  Once a stage (round) is agreed by all candidates and closed, there is no going
back, and you never go back to the beginning and start again except on the order of a Court after all the elections are over and all
the results declared.



> I'd much prefer a published ballot  
> file and counting program.

I am surprised they did not use a program for this are there are some open source programs available that implement a wide variety
of STV counting rules, though I haven't checked to see if any of them can cope with "equal preferences".

If you want to see the FULL results (including ballot data) from real public elections that used the WIGM version of STV-PR go to:

  http://www.glasgow.gov.uk/en/YourCouncil/Elections_Voting/Election_Results/ElectionScotland2007/LGElectionResults.htm     
where you will find the results for 21 such elections.  Open each ward individually and then click on the "Full Results" link
(bottom left) and SAVE the zipped folder.  In that folder you will find the full ballot data (as preference profiles in BLT format),
The STV Result Sheet is in the conventional UK format, but the full WIGM calculations for each stage are shown in the Audit file.

James

No virus found in this outgoing message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.17.12/1203 - Release Date: 30/12/2007 11:27