[EM] Pb is not monotone after all

Kristofer Munsterhjelm km_elmet at t-online.de
Wed Apr 28 01:28:00 PDT 2021


I was going through the "proof" that Pb (Plurality Benham) is monotone,
and then I found out it doesn't work after all, because it requires a
property that Plurality fails. I thought that the failure could only
happen in the case of a tie, but that's not the case.

Here's an example:

8: A>B>C
2: B>A>C
5: B>C>A
6: C>A>B

This is an ABCA cycle and the Plurality order is A>B>C. So C gets
eliminated whereupon A beats B pairwise and wins.

Now two B>A>C voters raise A. The result is

10:A>B>C
 5:B>C>A
 6:C>A>B

It's still an ABCA cycle, but now the Plurality order is A>C>B. So B
gets eliminated and then C beats A pairwise and wins. Raising A made A
lose -- monotonicity failure.

The base method property that I think will make a Benham-style algorithm
monotone is this: Suppose A is the winner and there's a cycle A>B>C>A,
with B>C in the base method's social ordering. Then raising A must not
move C above B in that social ordering.

Plurality, not having a concept of pairwise victories (much less
beatpaths), fails this. But it's far from clear how one might combine
this property with the pairwise burial immunity that Plurality does
have, and that's necessary for a Benham-style algorithm to pass DMTBR.

(Pairwise burial immunity: Voters who prefer Y to X can't push Y above X
in the social ordering by burying X on their ballots.)

But at least Pb shows that DMTBR + Condorcet + summability is possible.
That's something! (I didn't get what I expected - but I got something I
didn't expect.)

-km


More information about the Election-Methods mailing list