[EM] SODA criteria

[Kevin Venzke]

Hi Jameson,


De : Jameson Quinn <jameson.quinn at gmail.com>
>>À : Kevin Venzke <stepjak at yahoo.fr> 
>>Cc : em <election-methods at electorama.com> 
>>Envoyé le : Jeudi 2 février 2012 11h35
>>Objet : Re: [EM] SODA criteria
>>
>>
>
>>
>>
>>>
>>>
>>>>>
>>>>>
>>>>>In 
>>>>>>your criteria list you had "Majority" but for that you must actually be assuming the opposite of what I am trying, namely that
>>>>>>*everyone* is delegating, is that right?
>>>>>
>>>>>
>>>>>Everyone who votes for the majority candidate is either delegating to them, or voting them above all other alternatives - that is, approving only them but checking "do not delegate". This is the standard meaning of the majority criterion. For instance, by this meaning, approval meets the majority criterion.
>>>>>
>>>>>
>>>>>For MMC, everyone in the mutual majority is either delegating to one of the candidates, or approving all of them and nobody else.
>>>
>>>Oh, I missed that the voter can't rank at all. So you are good with FBC. But I don't regard Approval as satisfying what I
>>>call MF and Woodall's Majority. It's possible to say it satisfies MF, but I prefer Woodall's treatment.
>>
>>
>>I don't know what MF stands for. I agree that it fails Woodall's majority, though not in the unique strong Nash equilibrium.
>>
>>(The criteria framework
>>>I use doesn't have any way to say that Approval satisfies MMC. You can equate approval with equal-top, above-bottom, or
>>>call it something external, but I can't say that voters stick to a limited number of slots. I understand the meaning of "two-slot 
>>>MMC" or "voted MMC" but I see these as inferior versions.)
>>
>>
>>"voted", because delegation means there's sometimes effectively more than two slots. 
>>
>>>
>>>In response to your last line, if the majority set involves more than one candidate, the delegating voters are never part of it
>>>and are unnecessary in getting one of these candidates elected. (I'm using your treatment that voters only have two rank 
>>>levels.) If you don't agree, I'd like to hear how you are interpreting MMC, because I can't think of how else it would work.
>>
>>
>>10: A(>B>C>?...)
>>10: B(>C>A>?...)
>>10: C(>A>B>?...)
>>21: ABC
>>49: ????
>>
>>
>>One of A, B, or C must win.

MF is Majority Favorite.

If I understand you correctly, you're treating voters as casting either an approval ballot, or else one of the predeclared
preference orders. I guess that makes sense though it's quite tricky to analyze. If a voter is counted as voting A>B>C, it's
not possible to raise C above only B. But when I analyze this, it has to result in something consistent with the desired ranking
unless that's completely impossible. I guess that could only be A, AC, or ACB approval ballots. I think that would result in 
some criteria problems. For instance, suppose that A>B>C elects C, but A=C=B elects B. Since I look at how the voter 
wanted to rank, and not the options the method made available, I would call that a Mono-raise failure.

You might think that's unfair, but I don't know what framework you can suggest that will be more apparent and also allow
you to fairly evaluate something like Mono-raise.

Personally I think it would be easier to assume voters have no idea what candidates predeclare. In that case MMC doesn't
apply in your scenario above.

Granted, this might make it hard for criteria that are supposed to deal with optimal strategy assumptions or equilibrium.
I just don't worry about those criteria because I don't know how to evaluate them.

I also wanted to note, here instead of in a separate post, that I wonder about the FBC. I was thinking it must satisfy
it because you could cast an approval ballot, but that's not good reasoning (see: any Condorcet method). What if it
is possible to get a superior result by delegating your vote to someone other than your favorite? It's not clear to me
that this is impossible.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20120202/6d0b7ba4/attachment-0004.htm>