[EM] : Chicken problem (was: SODA and the Condorcet

[Juho Laatu]

I wrote:

> One thing that I did not cover explicitly is how to handle equality. I guess it is ok not to require clones to be separated from others but just require them to be next to each others. What I mean is that if A and B are the only clones and there are three candidates {A, B, C}, then e.g. a bullet vote A would be ok since we consider A>B=C to be clone compliant enough although A is here better than B, and C is equal to B (i.e. closer to B in some sense).


I should have covered also the other option of forcing clones to be separated from each others here since that may well be required in some methods. For example in multi-winner elections it is natural that support to one of the clone members always means support to all members of that group. In this case a bullet vote to A would be complemented to A>B>C (to show the separation between {A, B} and {C}) and not to A>B=C.

This way of handling ties would change also one line in the pseudocode that I gave. In this case it would be as follows.

- the preference relation after a clone set will be always a > relation (e.g. A1>A2=B>A3 becomes A1>A2>A3>B, i.e. "=B" will be changed to ">B" to separate the clone set from other candidates)

Maybe this second option should be kept as the default option since it is safer. It limits the set of allowed votes a bit but it meets better the needs of all methods.

Juho




On 8.8.2011, at 0.18, Juho Laatu wrote:

> Ok, I agree that you need a concrete enough description to check the properties of the method.
> 
> If the tree is (((A,B),C),D), then all of them are explicit clones at top level (trivial), A, B and C are explicit clones, and also A and B are explicit clones within those larger clone groups.
> 
> If you vote D>B>C>A, that is clone compliant with clone groups {A, B, C, D} and {A, B, C} but not with {A, B}. In the examples that I gave I assumed that the first occurrence of one of the members is the place where all the clones should be. That means that after B you must have A. The corrected vote would be D>B>A>C. As with the traditional clone definition, now all the clones stand next to each others.
> 
> You could read the vote e.g. so that after you have ranked D (one of the clones) first, you must rank A, B and C next. Although I didn't describe the process explicitly (only as an example), if you don't say anything about the others, the completion procedure should add them as equal after D (=> D>A=B=C).
> 
> One thing that I did not cover explicitly is how to handle equality. I guess it is ok not to require clones to be separated from others but just require them to be next to each others. What I mean is that if A and B are the only clones and there are three candidates {A, B, C}, then e.g. a bullet vote A would be ok since we consider A>B=C to be clone compliant enough although A is here better than B, and C is equal to B (i.e. closer to B in some sense).
> 
> You wrote about inferring structure from the votes. I however assumed that the trees would be agreed and announced already before the actual election day. Voters would be expected to respect that structure and not try to separate clones from each others. You could also derive the trees from the given votes, but of course that would be a more complex thing to do, and you would have to violate/modify some voter opinions that were cast without knowing that they violate the order in the post-derived tree. It is also hard to say which candidates should be declared as clones and which ones not. There is no requirement to have a full binary tree here.
> 
> (One could also avoid violating any voter's opinion if one would declare only those candidates as clones that meet the traditional very strict clone definition (= those who are next to each others in every vote). But that would be quite unnecessary since all the clones would already be their correct places.)
> 
> I don't think there is risk of losing monotonicity in the predecared tree + preprocessing + Condorcet approach if we assume that the Condorcet method is monotonic and the preprocessing rule just limits the set of allowed candidate orderings in the input votes. If we correct erroneous votes to clone compliant votes and that causes the result to change in a nonmonotonic way, that should maybe not be considered to be a violation of nonmonotonicity. If that is a problem, then we could just reject all badly formulated votes and not count them in any statistics. In that sense the method is just plain Condorcet with some strict rules on which votes are legal.
> 
> Yes, the SODA approach to the chicken problem is tree-like. The predeclared tree and limited set of acceptable votes approach could be seen as one straight forward and simple approach that can be used also as a measure stick to see how much other methods can improve from that.
> 
> I'll write also some pseudocode to make the vote correcting / complementing process more explicit.
> - derive clone sets from the candidate tree (every branch of the tree is a clone set whose members are all the candidates in that branch)
> - read every vote starting from the highest ranked candidate
> - if some candidate is not followed (without interruptions) by all the other candidates of a clone set whose member this candidate is, the vote must be corrected (or complemented if the omission of other clones was intentional)
> - start corrections from the smallest clone set, and then continue with the bigger ones (note that every clone set is a subset of all the other larger clone sets that include this candidate)
> - lift the other members of the clone set next to this candidate, maintain their relative order and preference relation between them (>, =)
> - the preference relation after the clone set will be the one that preceded the first non-clone-set-member below this candidate (e.g. A1>A2=B>A3 becomes A1>A2>A3=B, i.e. "=B" stays although the candidate before B changed)
> - note that after solving all smaller clone sets a larger clone set will not change the order of the already moved candidates since they are automatically part of the clone set, and already "well ordered"
> - note that when the vote reading process moves (after rearranging some clone sets) forward, some later candidates may cause changes in the order of the (later) already moved candidates (e.g. the already collected A* clone set in vote A1>A2>A3>A4>B could still become A1>A2>A4>A3>B if A2 and A4 form a clone set {A2, A4})
> (I hope that's detailed enough. Please point out errors. I'm getting too tired to check :-).)
> 
> Juho
> 
> 
> On 7.8.2011, at 22.22, Jameson Quinn wrote:
> 
>> 
>> I think the "explicit clone preprocessing of the votes + Condorcet" description that I gave below is a quite accurate definition of a method that both eliminates the clone problems and has rich ballots (rich enough to take position also on the order within the competing branch).
>> 
>> I still think you have to spell things out more for us. If the tree is (((A,B),C),D) and I vote DBCA, what does my vote get corrected to? And I can easily think of several variations of how to preprocess votes into clone trees. In general, I think methods which try to infer structure from votes are tricky. Either you're risking nonmonotonicity by reading in more than is really there, or you could end up just reinventing a complicated way to restate DSC/DAC.
>> 
>> Note that part of the SODA solution for the chicken dilemma -- that is, the enforcably-mutual preferences between candidates -- is tree-like. So I can see the potential advantages of trees, I just don't think it's fair to claim benefits for a method that's not well-described enough for us to construct pathologies.
>> 
>> JQ
>> 
>> 
>> ps. By the way, can anyone explain to me a scenario where DSC would be better than DAC? I understand that with full rankings they're equivalent, but I don't see when DSC is better.
>> ----
>> Election-Methods mailing list - see http://electorama.com/em for list info
> 
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info

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