Consider the following method:
First calculate the Ranked Pairs social ordering.
Then repeatedly:
- Check if any candidate has more than a Droop quota of first preferences.
- If so, elect that candidate and eliminate him.
- If not, eliminate the currently uneliminated candidate who's ranked
last on the RP social ordering.
- Repeat.
This should minimize the effects on nonmonotonicity due to loser
elimination. In IRV, the nonmonotonicity is entirely due to the loser
elimination effects, but Ranked Pairs passes LIIA and so loser
elimination should have minimal effect.
So, would this method be monotone? Probably not (maybe it has a failure
mode similar to the QBS), but it could be instructive to see just how
much monotonicity failure is due to winner elimination.
This method would be quite centrist/consensus biased in practice.
Whether that's a feature and a bug would be for people to decide. In one
dimension, imagine the distribution of support being divided into bins
that are each a Droop quota large. This method would (if I'm not
mistaken) elect the candidate closest to the center - i.e. closest to
the edge of the bin facing the distribution's median - in each bin.
Better would be this:
Repeatedly:
- Check if any candidate has more than a Droop quota of first preferences.
- If so, elect that candidate and eliminate him.
- Otherwise, do Ranked Pairs with the reduced ballots (currently
eliminated candidates removed), and eliminate the loser.
- Repeat.
That's more likely to fail monotonicity, but should be less
center-biased, and the nonmonotonicity events would be limited to when
the Ranked Pairs ordering changes due to a winner being eliminated.
(On a side note, if we had a method that would place candidates ranked
first by more than a Droop quota above any other candidates and would
pass LIIA, then we would definitely have monotonicity. But I don't think
that's possible, because this property implies majority in the
two-candidate case, and LIIA plus majority implies Condorcet, which is
incompatible with the DPC.)
-km
Consider the following method:
First calculate the Ranked Pairs social ordering.
Then repeatedly:
- Check if any candidate has more than a Droop quota of first preferences.
- If so, elect that candidate and eliminate him.
- If not, eliminate the currently uneliminated candidate who's ranked
last on the RP social ordering.
- Repeat.
This should minimize the effects on nonmonotonicity due to loser
elimination. In IRV, the nonmonotonicity is entirely due to the loser
elimination effects, but Ranked Pairs passes LIIA and so loser
elimination should have minimal effect.
So, would this method be monotone? Probably not (maybe it has a failure
mode similar to the QBS), but it could be instructive to see just how
much monotonicity failure is due to *winner* elimination.
This method would be quite centrist/consensus biased in practice.
Whether that's a feature and a bug would be for people to decide. In one
dimension, imagine the distribution of support being divided into bins
that are each a Droop quota large. This method would (if I'm not
mistaken) elect the candidate closest to the center - i.e. closest to
the edge of the bin facing the distribution's median - in each bin.
Better would be this:
Repeatedly:
- Check if any candidate has more than a Droop quota of first preferences.
- If so, elect that candidate and eliminate him.
- Otherwise, do Ranked Pairs with the reduced ballots (currently
eliminated candidates removed), and eliminate the loser.
- Repeat.
That's more likely to fail monotonicity, but should be less
center-biased, and the nonmonotonicity events would be limited to when
the Ranked Pairs ordering changes due to a winner being eliminated.
(On a side note, if we had a method that would place candidates ranked
first by more than a Droop quota above any other candidates *and* would
pass LIIA, then we would definitely have monotonicity. But I don't think
that's possible, because this property implies majority in the
two-candidate case, and LIIA plus majority implies Condorcet, which is
incompatible with the DPC.)
-km
