# Re: Ranked Choice Math

From: Charlie Strauss <cems_at_earthlink_dot_net>
Date: Tue Apr 08 2008 - 22:34:27 CDT

my 2 cents.

Instant Run-off voting might possibly be the worst possible way to do
ranked preference voting.
it's flaws include:

1) when there are three or semi- equal strong parties then it tends
to have three severe pathologies:
i) it normally chooses a candidate not preferred by the majority
(!)
ii) it is biased to fringe rather than centrist candidates
iii) you can game the system: by ranking a candidate you hate
first, you can sometimes improve the chances of you candidate winning

2) it destroys the "spoiler effect" thereby robbing weaker parties
of all power to get their agenda's co-opted by major parties. (This
is bad because the only thing keeping the two major parties from
becoming even more similar right now is that each must hedge away
from the center to co-opt possible fringe parties and to get people
in the fringe excited enough to vote. )

if you want to do ranked preference voting here are five approaches
that are always superior to IRV in my opinion.

1) "majority rule" (AKA condorcet) voting. Simply consider all
candidates pair wise by (virtually) eliminated all the others as
though they had never run and rolling over those votes to the two
virtual contenders according to the ranking. If one candidate beats
all comers then that person is preferred by a majority. If not you
apply a tie breaker rule or apply one round of IRV. This still has
defect 2 above but it always superior to IRV and take no extra
effort. Under _most_ real world conditions this is provably
satisfies all of Arrows axioms of fairness, though in theory it can
occasionally fail in extreme cases.

2) Range voting. Like netflix. Rate every candidate with 1 to ten
stars. Candidate garnering most stars wins. In theory if every one
is honest this is provably both the bayes optimal and arrow optimal
candidate. However in practice people will not honestly rate their
preferences and are driven towards binary ratings as an optimal game
theory approach (ranking some ten and everybody else zero). Which
means it can approach Approval voting.

3) Approval Voting: Mark the oval next to candidates you approve
of. Mark as many as you wish. Candidate with the most marks wins.
Nice thing about this is that it works with existing paper ballots
and existing voting machine software, and does not make the ballots
longer. It's simple and easily understood. It approximates Range
voting and thus will approximately approach the bayes optimal and
arrow optimal candidate choice. For these reasons this should be
highly considered.

4) "candidate chooses". Instead of voters ranking the candidates the
candidates rank the candidates including themselves. Then when you
vote for a candidate you get her ranking. Now you resolve this by
whatever Ranked preference process you like. Like approval voting
the ballots and voting machine software are unchanged from the present.

The nice thing about the last one is that while it elimates spoilers
hurting major candidates it does not remove the ability of weak
candidates to negotiate to get their agenda adopted. Some might say
it gives too much power.

therefore a compromise is:

5) hybrid candidate chooses. Here the voter can choose to rank the
candidates or just pick one and let that candidate choose.

Finally: deep ranking:
it is not a great idea to encourage deeply ranked preferences.
People know who they like, who they hate and who's their fall back.
The middle tier candidates are not going to be well researched by
voters. Thus rankings beyond say, 3 deep, are noise. In systems
like IRV, noise makes the system quite unstable. Condorcet is
significantly more stable but is still prone to noise.

In the unlikley event a contest is undecided after 3 rounds it would
be much better to either have a real run-off so people can now study
the remaining few, or to revert to candidate-chooses as the fall back
for deep ranking.

p.s. in many countries where IRV is used it's used in a different
way. It's either part of a multi-member voting system (new zealand) ,
there are other ways votes get shifted (au and ireland), or it's used
in a party-centric rather than candidate centric ways. All those
ameliorate it's flaws making it more tolerable. But for choosing
single seats it's probably the worst way to do ranked preference
voting as measured by Arrows axioms or bayes optimality.

On Mar 27, 2008, at 2:03 PM, Dylan Hirsch-Shell wrote:
> I don't like how ties are handled in that example. In round 2,
> three of the candidates were eliminated because they were all tied
> for the lowest number of votes (15), but I'm not so sure that the
> outcome would have been the same if some subset of those 3
> candidates were eliminated in that round. Wikipedia has a short
> list of tie-breaking rules that are used in real elections.
> Usually, if the combined vote total for all the tied candidates is
> smaller than the number of votes for the next weakest candidate,
> then all the tied candidates are eliminated. That wasn't the case
> here (15*3>16). In Australia and Ireland they look to previous
> rounds and eliminate the candidate who had the fewest votes there,
> but that still wouldn't break the tie in this case. This shouldn't
> be a problem with more ballots or fewer candidates, but it's
> probably still worth trying to find a solution..... Maybe running
> multiple versions of the next round in parallel to see whether
> certain candidates would always be eliminated anyway?
>
> On Wed, Mar 26, 2008 at 7:37 PM, Danny Swarzman
> <danny@stowlake.com> wrote:
>
> On Mar 26, 2008, at 12:14 PM, Alan Dechert wrote:
>
> >
> > I've been showing our demo to registrars around California. Here's
> > one
> > thing we will add for sure: When the tabulation program is done, we
> > print
> > the results to a file and put it on the desktop. I want to add a
> > barcode to
> > the page, which has the precinct tallies encoded in the barcode
> > (actually,
> > Elaine Larson of Santa Clara Co. said she wants that). That way,
> > they can
> > aggregate the vote by scanning the barcode on each tally sheet from
> > the
> > precincts.
> >
> > I also want to handle ranked choice in the barcode. In our old
> > demo, we
> > only tried to show how many times a candidate got a particular
> > ranking.
> > This could only serve as a kind of checksum -- you can't actually
> > use this
> > information for determining the winner.
> >
> > I think we will win some points if we can capture the rankings in
> > the tally.
> > Now that we have moved to 2-d barcodes, it's feasible to do this.
> >
> > There may be many more possible rankings than actually appear on the
> > ballots
> > cast at any particular precinct. For example, if you had eight
> > candidates
> > and you allowed ranking up to three of them, there would be 8*7*6
> > (all the
> > ways of ranking all three) plus 8*7 (all the ways of ranking two)
> > plus 8
> > (ways to make only a first choice)... or a total of 336+56+8 = 400
> > possible
> > rankings. There going to be many more Possible Combinations than
> Used
> > Combinations.
> >
> > Let's say we have eight candidates, A - H. We could represent the
> > Used
> > Combinations like this:
> > BC20;DFG3;AC6; ... and so on, where BC20 means there were 20 ballots
> > where B
> > was ranked first and C was second with no third choice indicated.
> > DFG3
> > means there were 3 ballots where D was ranked first, F second and G
> > third.
> > This is not very efficient, but it's pretty easy to understand.
> > Maybe it's
> > good enough for demo purposes.
>
> San Francisco has had over 20 candidates in some contests.
>
> >
> >
> > With 2-d, we have a lot more data we can put in the barcode, but
> > there are
> > limits. We can also put multiple barcodes on the tally sheet. What
> > if
> > there are many ranked choice contests on a ballot?
> >
> > Write-ins could play havoc with ranked choice calculations. As long
> > as
> > write-in candidates are not popular, they won't figure in the
> > calculations.
> > In this example, we could designate H as the write-in. Only if the
> > number
> > of votes for H reaches a certain threshold will H have to be sorted
> > out and
> > the ballots examined to see who all the H votes are for.
> >
> > Right now, I'm not too concerned with how the ballots from the
> > precincts
> > will be aggregated. I only want a good method for presenting the
> > results
> > from the precinct -- encoding them in the barcode.
> >
> > Jan is likely to be the one that will do the coding for this.
> > However, I
> > want to know if anyone wants to help investigate some of this before
> > we
> > decide.
> >
> > There are a number of questions to look at. For example,
> >
> > - How many candidates is the voter ordinarily allowed to rank? (I
> > think it's
> > 2 or 3 but don't have much evidence).
>
> San Francisco requires at least 3. Under the old (ES&S) system, there
> were exactly 3.
> >
> >
> > - Do ballots sometimes have multiple ranked choice contests? How
> > many? Is
> > this likely to increase in the future?
>
> I think that San Francisco can have 3-4 city-wide plus one per
> district.
> >
> >
> > - What is typical for Used Combinations as a percentage of Possible
> > Combinations?
> >
> > - In the example above, it's taking an average of about 5 characters
> > (including a delimiter) for each Used Combination. Will we need to
> > make
> > this more compact? If we need to get it down to 2 or 3 characters
> > per Used
> > Combinations, what are some schemes for doing this (and that will be
> > reliable and not too difficult to audit)? Can we use 7-bit or 8-bit
> > characters instead of numbers?
> >
> > - Ranked choice is not widely used but is becoming more popular.
> > What are
> > some of the standards that are emerging with respect to ranked
> choice?
>
> San Francisco uses Instant Runoff Voting. See http://stowlake.com/
> RankedChoiceVoting.html
> .
>
> >
> >
> > _______________________________________________
> > OVC-discuss mailing list
> > OVC-discuss@listman.sonic.net
> > http://lists.sonic.net/mailman/listinfo/ovc-discuss
> > By sending email to the OVC-discuss list, you thereby agree to
> > release the content of your posts to the Public Domain--with the
> > exception of copyrighted material quoted according to fair use,
> > including publicly archiving at http://gnosis.python-hosting.com/
> voting-project/
>
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss
> By sending email to the OVC-discuss list, you thereby agree to
> release the content of your posts to the Public Domain--with the
> exception of copyrighted material quoted according to fair use,
> including publicly archiving at http://gnosis.python-hosting.com/
> voting-project/
>
> _______________________________________________
> OVC-discuss mailing list
> OVC-discuss@listman.sonic.net
> http://lists.sonic.net/mailman/listinfo/ovc-discuss
> By sending email to the OVC-discuss list, you thereby agree to
> release the content of your posts to the Public Domain--with the
> exception of copyrighted material quoted according to fair use,
> including publicly archiving at http://gnosis.python-hosting.com/
> voting-project/

_______________________________________________
OVC-discuss mailing list
OVC-discuss@listman.sonic.net
http://lists.sonic.net/mailman/listinfo/ovc-discuss
By sending email to the OVC-discuss list, you thereby agree to release the content of your posts to the Public Domain--with the exception of copyrighted material quoted according to fair use, including publicly archiving at http://gnosis.python-hosting.com/voting-project/
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Wed Apr 30 23:17:02 2008

This archive was generated by hypermail 2.1.8 : Wed Apr 30 2008 - 23:17:05 CDT