Fw: counting preferential ballots

From: Alan Dechert <alan_at_openvotingconsortium_dot_org>
Date: Thu Oct 28 2004 - 10:48:48 CDT

----- Original Message -----
From: "Hubert Bray" <bray_at_math_dot_duke_dot_edu>
To: "Alan Dechert" <alan@openvotingconsortium.org>
Sent: Thursday, October 28, 2004 8:46 AM
Subject: Re: counting preferential ballots

>
> Dear Alan,
>
> Sure, I would like to join your email list. Please add me. Also, if you
> could forward this email to the list that would be great. I have spent
much
> time studying preferential ballot vote counting methods and would be happy
to
> contribute in this area.
>
> I am a very enthusiastic proponent of preferential ballot elections, but
only
> if the votes get counted in a reasonable manner. However, it is not
generally
> understood by the general population how one determines a winner with
> preferential ballots. Even worse, there are dozens, if not hundreds, of
> different preferential vote counting methods which, unfortunately, produce
> -different- results typically. I have focused on determining criteria for
> deciding which are the best vote counting methods.
>
> Bad vote counting methods would include those that can be manipulated by
> politicians too easily. For example, point counting methods (5 points for
> each 1st choice, 4 points for each 2nd choice, etc.) can be manipulated by
> political parties by flooding the election with numerous similar
candidates.
> If one thinks about it, it is possible to come up with scenarios in which
the
> most popular candidate does not win (even when a candidate is the first
choice
> of 60% of the people).
>
> The two most important properties that I think that preferential vote
counting
> methods should have are
>
> 1) If Candidate A can beat any one of the other candidates in a
> vote, then Candidate A should be declared the winner.
>
> 2) "Cloning" candidates (that is, having your 5 brothers running on the
> ballot representing exactly the same viewpoint) should not make a
difference
> in the outcome of the election.
>
> Candidates who can beat any other candidate in a head-to-head election
(which
> is possible to simulate based on people's listed preferences) are called
> "universal winners" (also called Condorcet winners). A universal winner
does
> not always exist, but there can be at most one universal winner. I think
that
> property (1) is important because this property gives a clear goal to each
of
> the candidates: If you can become more popular than any other single
> candidate, then you win the election. Also, it seems unfair to me to say
that
> Candidate B wins the election even though Candidate A would beat him (and
> every other candidate for that matter) in a head-to-head contest.
>
> Property (2) is important for two reasons. Clearly you don't want
candidates
> to purposely clone themselves for a political advantage, so cloning
oneself
> shouldn't help that candidate. On the other hand, you don't want to
penalize
> candidates who happen to all want to represent a similar, popular
position.
> Since cloning should therefore neither help nor hinder a candidate,
cloning
> shouldn't make any difference at all.
>
> Philosophically speaking, one might want to add other "Ideal Properties"
for a
> vote counting system to have, but it turns out that it is easy to come up
with
> so many "good" properties than no vote counting system can satisfy all of
> them at the same time.
>
> My two favorite vote counting methods are the "Least Worst Defeat" method
> (LWD) and the "Ranked Pairs" method (RP). RP is arguably the best method,
but
> LWD is almost as good and is easier to understand. Both methods determine
a
> winner using the "Margin of Victory Matrix," which we will call M.
>
> If there are n candidates in the election, M is an n x n matrix. The
number
> in row i, column j of M (which we will call M_ij) is the "margin of
victory"
> of candidate i over candidate j, defined as follows: Going through all of
the
> preferential ballots, define M_ij to be the number of voters who prefer
> candidate i to candidate j MINUS the number of voters who prefer candidate
j
> to candidate i. In other words, if these voters had been just voting
between
> these two candidates, M_ij is the number of votes candidate i would have
beat
> candidate j by (and is negative is the case that candidate j would win).
All
> unranked candidates are assumed to be tied for least favorite for that
voter,
> and if both candidates are unranked by the voter, that vote does not
> contribute to M_ij. Also, since every candidate ties with himself, the
> diagonal entries of M are all zero.
>
> Since M_ji = - M_ij, the n x n matrix M is called an "anti-symmetric
matrix."
> If the election is being held in multiple precincts, then each precinct
should
> determine the Margin of Victory Matrix for their precinct and then all of
> these matrices should be added together to get the Total Margin of Victory
> Matrix for the election.
>
> In other words, at some point, I would like to suggest that your software
> should compute the Margin of Victory Matrix M defined above in each
> precinct. This is the most important statistic to keep track of.
>
> Given M, we now know how each candidate would do against any other single
> candidate. In particular, each candidate has a "worst defeat" to some
other
> candidate by some number of votes. Whichever candidate has the least
"worst
> defeat" is the winner as determined by the LWD method. Notice that LWD
> satisfies both (1) and (2). Property (1) is satisfied since a universal
> winner doesn't have any defeats (so one could say his worst defeat equals
zero
> since he ties with himself). But since a universal winner beats all other
> candidates, every other candidate will have at least one defeat by some
> positive number of votes. Property (2) is satisfied since cloning
candidates
> does not change the value of a candidate's worst defeat to any of the
other
> candidates.
>
> The Least Worst Defeat (LWD) vote counting method is great because it is
easy
> to understand and has good properties. I can describe the Ranked Pairs
(RP)
> method at some future date if you like. Philosophically the RP method is
> slightly better (and not too hard to understand). However, as long as
your
> software computes the margin of victory matrix M, the RP method can still
be
> used to determine a winner.
>
> Bottom line, let me strongly suggest that the margin of victory matrix M
is
> the most important statistic to keep track of when counting votes. Then
the
> people conducting the election will have a number of very good
preferential
> vote counting methods by which to determine a winner.
>
> Best,
> Hubert Bray
>
>
>
>
> On Oct 27,2004 16:00:54 -0700, Alan Dechert
<alan@openvotingconsortium.org> wrote :
> >Greetings Hubert!
> >
> >We usually refer to these as "ranked preference contests." We plan to
> >support whatever scoring methods are in use. Our prototype doesn't, at
this
> >point, go beyond the precinct level. Here we only tally "so many 1st
place
> >votes for candidate x, so many 2nd place votes for candidate x, etc.
> >
> >If you want to join our email list to discuss your ideas, I would be
happy
> >to add you. Right now, we're focused on raising some money. With luck,
> >we'll have this worked out within the next month or so.
> >
> >Alan Dechert
> >
> >
> >>
> >> Question: Does your software count votes as well? If so, how do you
> >> count the preferential ballots? If not, do you have plans in this
> >> direction? I have studied the different vote counting methods for
> >> preferential ballots extensively and would be happy to help in this
> >regard.
> >>
> >> Best Regards,
> >>
> >> Hubert Bray
> >> Professor of Mathematics,
> >> Duke University (on leave from Columbia and MIT)
> >>
> >
> >
>
>
> Hubert Bray
> Mathematics Department
> Duke University
>
>
>
>
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Mon Nov 1 15:28:52 2004

This archive was generated by hypermail 2.1.8 : Mon Nov 01 2004 - 15:28:58 CST