[EM] Pb is not monotone after all

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[EM] Pb is not monotone after all

Kristofer Munsterhjelm-3
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
----
Election-Methods mailing list - see https://electorama.com/em for list info