[EM] Are tied rankings valid in IRV?

Alex Small asmall at physics.ucsb.edu
Sat Apr 19 22:51:01 PDT 2003


I've thought about this myself, in thinking about the FBC issue.  As it is
currently defined, IRV really has no place for tied rankings.  Handling
tied rankings requires that we make some decisions about how we want it to
work.

First, in the case of multiple majorities (e.g. 2 candidates getting
first-place votes from a majority of the voters because of people ranking
multiple candidates in first place) it seems most natural to elect whoever
has the largest majority.  This is not the only possible means of
resolution, since we could have opted to continue eliminating other
candidates and transferring votes.  However, it seems the most natural
method.

Second, suppose that you rank multiple candidates in first place, and one
of them is eliminated.  Should your second place candidate (or candidates)
receive votes while you still have a first-place candidate on the ballot? 
I say no, don't transfer votes to the candidate (or candidates) in the nth
rank until ALL candidates ranked n-1 or higher are eliminated.

OK, these are obvious generalizations, but they aren't the only options,
so I think it's important to state these rules explicitly to facilitate
the examination of equal rankings in generalized IRV.  Otherwise we could
get arguments like "We do it this way!" "No, that way!"  "No, this way!"
when the more productive/interesting arguments would be "If we assume that
this is the way of doing it, what is the optimal strategy?  What is the
most likely outcome in a typical race?"


Let's look at a scenario where IRV encourages insincere rankings, and see
if generalized IRV would encourage equal rankings rather than reversing
the order of 2 candidates.

Say that your preference is A>B>C, and no candidate has first place votes
from a majority of the voters but C has the lead in first place votes. 
Say that B beats C pairwise, and C beats A pairwise.

You don't want B to be eliminated, so you definitely rank him first. 
However, you do want A to be eliminated.  Although there will be cases
where ranking A and B equal will suffice to push B ahead of A, there will
still be cases where you also want to rank A second, to ensure that A is
eliminated rather than B.


A second case:  Your preference is still A>B>C.  A has enough first place
votes to not be eliminated, but B and C are in a close race.  A beats C
pairwise but B beats A pairwise.  You want B to be eliminated, so you
don't rank him equal to A, but you want C to advance, so you rank him
equal to A.  There's no disincentive to rank A in first place, so your
ranking should be A=C>B.

(Of course, if too many people do this then C might beat A pairwise in the
second round, but that's also true in regular IRV when there's an
incentive for some of A's supporters to rank a "soft target" in first
place.)


Although that is hardly an exhaustive analysis, it seems that equal
rankings in IRV would reduce but not eliminate the incentives for
insincere ranking.



Alex

Rob Lanphier said:
> Hi all,
>
> I'm doing some analysis of the Debian Project Leader election, and I'm
> trying to figure out who would have won that election had IRV been
> used.  In doing this, it seems the election was close enough that it
> matters whether or not tied rankings are allowed.  Many of the voters in
>  that election voted for multiple candidates as their first choice
> candidate.
>
> It strikes me that allowing for tied rankings would make IRV behave much
>  like Approval.  If one ranks all "approved" candidates first in an IRV
> election, one could keep those candidates from getting eliminated in the
>  early rounds.  This not only seems like a good strategy...it seems like
>  the only winning strategy.
>
> If that's the case, and IRV with tied-rankings works similarly to
> approval, would this be a good suggested improvement/clarification for
> IRV advocates?
>
> Rob
>
>
> ----
> Election-methods mailing list - see http://electorama.com/em for list
> info






More information about the Election-Methods mailing list