[EM] Burlington manifesto - for Condorcet
Dave Ketchum
davek at clarityconnect.com
Sat Nov 19 13:00:21 PST 2011
On Nov 6, 2011, at 8:41 AM, Jameson Quinn wrote, as Burlington
manifesto:
> (Note: The email subject is mostly a joke; I doubt this email will
> be coherent and enduring enough to be considered a manifesto. Also,
> if you skip to the bottom, I'll talk a bit about how my recently-
> proposed 321 voting system is slightly better than I'd thought/said
> earlier.)
While his words make some sense, I am writing only to promote
Condorcet, especially as better than IRV - one of the lessons to learn
from Burlington.
* I cannot resist some thoughts now, tagged this way, that perhaps
do not have to be in the final product.
While there are many Condorcet methods, I will concentrate on details
that all good methods should share.
* We allow ranking and voters should rank each, PROVIDED they would
find each acceptable to win. No need to even rank these past almost
certainly ranking an expectable winner.
* BUT, they should not rank those they hope will lose. Anyway, in
many races there is one candidate many agree should win and voters who
agree may not see value in voting for the deserving winner - it is
when we disagree that we need to rank all that we see as approvable.
* This is a path out of major parties owning it. Voters can vote
for both a major party and a truly liked - and see from x*x how well
liked is doing even if not winning.
Thus I see ranking only one as often the best a voter can do, and
rare for a good voter to wish to use more than 3 ranks.
Ballots must allow ranking one or more candidates, with the maximum
being three or more ranks (decided in compromise between cost and need).
A - each candidate ranked is preferred over every unranked
candidate.
A>B - of every pair of candidates with unequal ranks, the one
with higher rank is preferred over the other.
A=B - every group of two or more candidates with the same rank
share equal preference.
Write-in - either an A or B.
The x*x matrix is what we read ballots into. I do have a thought that
would both decrease the labor and also simplify if, for example, some
precincts, for some reason, had more candidates than others:
Establish a C array to contain how many voters vote for each
candidate. Then finish up by adding the C count for each candidate
into each element in that candidate's row in x*x - less effort than
adding '1' to each element in that row for each voter who votes for
that candidate.
Now to x*x. This will do what we need for each pair that combines a
voted candidate with one not voted for. But, we are adding to the
count for both candidates when both are voted for:
We are right for the winner of the pair.
For the loser, count -1 when reading that ballot - then later
reading from C will net zero for the loser while the winner will get
the desired +1.
What of ties? Let them both count a win in x*x but count the tie in
y*y. When reading from C, adjust per y*y.
* I claim C is worth doing even when each precinct has an identical
set of candidates.
* Write-ins should be considered essential because, when needed,
the need can be desperate. Try an example this year near where I live
- look at vote counts of the 3 voted for:
332 - current officer - has friends AND enemies.
100 - nominated - but then decided not to run.
537 - write-in - who became a candidate to replace above, but
too late for nomination.
* Write-in optimization suggested: Treat write-ins, collectively,
as a candidate. Usually this candidate will demonstrate losing. If
more votes, such as above 537, there may be a winning write-in, so go
back and see.
The CW (Condorcet Winner), if any, wins very one of its pairs with
other candidates.
Else we have a cycle such as A>B>C>A.
If one of the pairs in a cycle is within a couple of being a tie and
the other links are far from a tie, break the small link to treat what
remains as having a CW (numbers are 2 and 10, unless others are
specified for a use)..
There are many methods to choose from for remaining cycles.
>
> Jameson
More information about the Election-Methods
mailing list