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