[EM] MCA on electowiki

[Jameson Quinn]

In case you're wondering about a real example of MCA-P failing participation
(and, in fact, mono-add-top), here it is. Situation before:

1 vote: A>B
1 vote: C>B
1 vote: D>B
1 vote: E
1 vote: F
1 vote: A

No majorities, so, since it's MCA-*P*, the highest *P*reference wins; that's
A. (Exactly 50% isn't a majority. If it were, you could just add one G vote
to the example.)

Now, add another A>B vote. A still isn't preferred by a majority (only 3/7),
but B now has a majority approval (4/7). So B wins.

Two points about this example: it took a lot of candidates, carefully
balanced; and the participation-violating final A>B vote was unstrategically
extending approval. Simple strategy says that if you prefer one frontrunner,
you shouldn't approve the other one; so the voters must not have known the
true frontrunners.

Yes, it's still unfortunate. But I'd bet that if you model how frequently in
any given random elections model some voters would have reason to regret
their participation, it would be somewhere well under 5%, probably under 2%;
and any foreknowledge and strategy would tend to reduce that number even
further.

JQ

2010/10/19 Kristofer Munsterhjelm <km-elmet at broadpark.no>

> Kathy Dopp wrote:
>
>  The mathematical definition of increasing monotonicity says when I
>> increase the independent variable, the dependent variable likewise
>> increases (for voting, when I increase votes for a candidate, that
>> candidate's chance of winning increases.)  Or the mathematical
>> definition of nondecreasing monotonicity says, when I increase the
>> independent variable, the dependent variable never decreases (for
>> voting when I increase votes for a candidate, the candidate's chances
>> of winning never decreases.)
>>
>> I would say by any standard normal mathematical definition of
>> monotonicity, if a voting method fails the Participation Criterion you
>> linked to, it also fails to be monotonic.
>>
>> Adding votes or increasing ranking for a candidate, should not cause
>> that candidate to lose whereas he otherwise might have won.  To me,
>> that is just another way of stating nonmonotonicity.
>>
>
> Using Woodall's terms, the full name of what we usually call "monotonicity"
> on this mailing list is "mono-raise". That is: monotonicity regarding
> raising (ranking higher) a candidate. There are many other forms of
> monotonicity: for instance, mono-add-top (adding a vote that ranks a
> candidate first shouldn't make the candidate lose), mono-append (adding a
> candidate to a truncated ballot should not make that candidate lose), and so
> on. See http://www.votingmatters.org.uk/ISSUE3/P5.HTM for the full list.
>
> Any of these might be called monotonicity criteria, since they involve
> situations where ballots are added or altered in a way that is seemingly
> favorable for the new candidate, and the method fails the criterion if the
> candidate loses.
>
> As for Participation, Woodall says: "There is also the following property,
> which is not strictly a form of monotonicity but is very close to it. (...)
> Participation. The addition of a further ballot should not, for any positive
> whole number k, reduce the probability that at least one candidate is
> elected out of the first k candidates listed on that ballot. ".
> It is, unfortunately, a very strict criterion. Only voting methods that
> consist of point systems with point system tiebreakers (not necessarily the
> same tiebreakers) can fulfill it. A point system is one where you give the
> first candidate on a ballot x points, the second y points, the third z
> points, etc. DAC/DSC is in this sense a series of point systems, each
> breaking ties of the last.
>
>
> In summing up: what we call "monotonicity" is just one form of
> monotonicity, that is true; and it is unfortunate but also true that most
> complex systems fail Participation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20101019/41367df5/attachment-0004.htm>