These observations are very interesting but the incident in Aspen cannot be
dismissed simply as a mix-up in the parameter setting.
It is irresponsible (criminally irresponsible ?) for any election official to
authorise the use in public elections of any software
that has not been shown (and certified ?) to comply 100% with the Election Rules
specified for that particular election.

The lack of real understanding of STV (both as IRV in single-seat elections and
as STV-PR or RCV in multi-seat elections) is part of
the problem. This is compounded by some of the program writers who develop a
program fro one particular STV election and think it
can be used for STV elections elsewhere without fully understanding the subtle
but vital differences in the local election rules.
(I have so far identified seven different ways of transferring surpluses.)

If the Aspen incident was indeed the result of a mistake in the parameter
setting for that particular program , it raises a very
interesting question about the use of such multi-option software to count
ballots in public elections. In this case, it appears to
have been a mistake, an accidental incorrect setting, and the consequences of
the wrong setting were obvious in the results. But
what is to prevent an election technician with the relevant knowledge from
deliberately setting some parameters incorrectly in the
hope of biasing the result in favour of some candidate or party and in a subtle
way that would not be so obvious in the results?
Ideally, the unwanted multi-option code should have been removed from the
program before certification or the multi-option
parameters should have been locked down before certification so that they could
not subsequently be changed, either accidentally or
intentionally.

The only way to check that any computerised count has been done correctly, fully
in accordance with the relevant Election Rules, is
to publish all the ballot data (as preference profiles) after the election so
that anyone can run the data through any other program
that matches the relevant Election Rules.


I would also suggest that some of these problem would be avoided if the programs
for single-seat STV (IRV) counts used a completely
different algorithm from that for STV-PR, based on the simplified rules for
single-seat STV (= IRV, = Alternative Vote) that I
codified for the Electoral Reform Society in 1978. These Rules, with very
slightly modified wording, can be found on the ERS
website at:
http://www.electoral-reform.org.uk/article.php?id=116
Importantly, in these single-seat rules there is no calculation of a quota
(threshold) and no reference to "surplus" as there cannot
be any.


With regard to the specific observations:

Cambridge MA transfers surpluses only of first preference votes. Their version
of STV-PR (uniquely, I think) prevents surpluses
from arising at subsequent stages (rounds) and so there is no provision in those
rules for dealing with consequential surpluses.

Cambridge MA is not alone in transferring all transferable votes, even after the
required number of winners has been identified.
This is done in the manually counted STV-PR elections to the Dáil Éireann
because the rules on refunding candidates' money deposits
are based on the proportion of the votes each candidate has AFTER all votes have
been transferred. This adds otherwise unnecessary
rounds (stages) to the count.

There is a similar provision for transferring all votes in the Election Rules
for the STV-PR Local Government elections in Scotland
when the ballots are counted electronically. There is no need for this, because
there are no deposits in the elections, and it
means that a ballot with all preferences marked would be treated differently
from a ballot with the last preference blank, even
though the intention of both voters was identical. This "transfer all votes"
provision is highly undesirable as it can have the
effect, in a single-seat election, of transferring your vote to a candidate you
placed below ALL the other candidates. I hope we
shall be able to get this unnecessary and undesirable provision removed from the
STV-PR Rules we shall use for the local government
elections in Scotland in 2012.

James Gilmour


> -----Original Message-----
> From: stv-voting@yahoogroups.com
> [mailto:stv-voting@yahoogroups.com] On Behalf Of Jim Riley
> Sent: Friday, May 29, 2009 11:18 PM
> To: stv-voting@yahoogroups.com
> Subject: Re: [stv-voting] Check the software matches the rules
>
>
> It appears that the mixup may have been a parameter setting.
>
> If you compare the results from Burlington, VT, which used AV
> for its mayoral election in 2009.
>
> http://www.burlingtonvotes.org/20090303/2009%20Burlington%20Mayor%20Round.htm
>
> And Cambridge, MA which used multi-seat STV for its city
> council elections in 2007.
>
> http://www.cambridgema.gov/election/Electionresults_archives.cfm
>
> And Aspen, CO which used AV for its mayoral elections and
> city council elections in 2009.
>
> http://www.aspenpitkin.com/depts/38/
>
> They were all apparently done with the same vote tallying
> software. In Burlington the "system" was "Instant Runoff
> Voting", and had no parameters for handling surpluses. In
> Cambridge and Aspen it was "Choice Voting", and the
> paremeters described for handling surpluses (or avoiding
> surpluses). If you follow the link at the bottom of the
> result pages, you will see that "Choice Voting" = multi-seat STV.
>
> Cambridge, like the Republic of Ireland, transfers selected
> ballots from surpluses, rather than all ballots from a
> transfer with a fractional transfer value.
>
> But Cambridge prevents surpluses on subsequent counts.
> Ballots are transferred serially, and once a candidate
> reaches the quota during a count, subsequent transfers to
> that candidate are redirected to the next preference. If all
> expressed preferences have been exhausted, a ballot that
> forms part of the quota, and does have further preference may
> be transferred in place. If you look at the Cambridge
> results, you will notice that elected candidates always
> exactly reached the quota, since any ballots that would have
> formed a surplus or further distributed in the same count.
>
> That is what happened in Aspen. The exclusion of the 3rd
> place candidate caused the leading candidate to reach the
> quota in a fairly close race. This was after 93.9% of the
> 3rd place candidate's votes had been transferred. The
> remaining 6.1% of the ballots were redistributed to the 2nd
> place candidate or exhausted.
>
> Overall, it changed the distribution of Erspamer's votes from the
> actual:
>
> Ireland 40%; Marks 43%; exhausted 17%, to that shown on
> election night of Ireland 34%; Marks 47%; and exhausted 19%.
> Thus the election night results were not totally implausible.
>
> Had the count been something like Ireland 49%; Marks 31%, and
> Erspamer 20% before Erspamer's elimination, the election
> night results could have shown Marks receiving 90%+ of
> Erspamer's transfers, and consequently almost catching Ireland.
>
> Cambridge has an additional quirk. They continue to transfer
> ballots even after it is impossible for a candidate to be
> elected (eg when N+1 candidates are either elected or
> continuing). In Cambridge, the ballots of the last placed
> candidate are formally transferred. In a multi-candidate STV
> election, this will tend to cause all elected candidates to
> achieve the quota (see 10th round of the 2007 Cambridge election).
>
> But in the city council elections in Aspen, the winning
> candidate did not reach the quota after elimination of the
> 3rd place candidate (there were more candidates running for
> city council, and Aspen used a weird way of applying AV, so
> that more exhausted preferences were likely). So in those
> races, the ballots of the 2nd place candidate was
> redistributed, which pushed the winning candidate up to the
> quota, but then caused most ballots to be exhausted since
> there were NO continuing candidates. As a result, all
> elected candidates in Aspen received exactly 1273 votes on
> election night.
>
> On Thu, 28 May 2009 23:20:59 -0000, "James Gilmour"
> <jgilmour@...> wrote:
>
> >City of Aspen Press Release:
> >Mayoral Vote Tally Corrected; Outcome Stays the Same
> > http://theredant.squarespace.com/storage/TallyCorrectedTB.pdf
> >
> >This should be a wake-up call to all who are working on or using
> >computer programs to count STV ballots.
> >
> >It is essential that the algorithm in the program implements the
> >specified election rules exactly. Ideally, all programs
> used in public
> >elections should be independently certified against the relevant
> >election rules before they are used.
> >
> >The feature that reportedly caused the problem here is
> specific to the
> >Cambridge MA election rules for multi-seat STV elections.
> This feature is of no relevance for single-seat STV elections
> and should not have been enabled for a count of a single-seat
> election.
> --
> Jim Riley

No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.339 / Virus Database: 270.12.46/2143 - Release Date: 05/30/09
05:53:00