Re: [EM] : Chicken problem (was: SODA and the Condorcet
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
Re: [EM] : Chicken problem (was: SODA and the Condorcet
2011/8/7 > To sum up my point of view suppose that the candidates publicly announce > the respective preferences > (with levels of support shown): > > 48 A > 27 C>B > 25 B > > I'm going to cut you off right there. Although the rest of what you say includes interesting points, I'd like to tell you how I envisioned solving this. C has some way of saying to B, before voting occurs: "Either include me in your preference order, or I won't include you." At that point, whether B and C are bluffing is obvious before voters have to vote. > We cannot tell from these ballots alone if B is bluffing or if B really > despises A and C equally. > > If the decision is made only on the basis of these ballots, then the right > decision for the case when B is > bluffing will be the wrong decision for the case when B is not bluffing, so > no method that relies on the > ballots alone will solve the problem. > > But if C is allowed to play before B, and C strongly believes that B is > bluffing, then C can "bullet." > > If C is right, then B will approve C also, and C will win. If C is wrong, > then A will win. > > Under actual conditions it is very unlikely that C is going to guess > wrongly as to whether or not B is > bluffing. > > SODA allows C to play before B, so the problem is basically solved, as long > as B is allowed to approve > someone that she did not rank on her ballot, or else as long as there is a > very strong incentive for B to > rank significant preferences. > Despite the fix above, this situation could still conceivably happen (if C backed down from the "you'd better approve me or else" bluff). It might be nice if there were some way to complete B's preference rankings so that they can approve C. But I don't want to make it possible for any candidate to approve anyone unapproved; I think that is too likely to lead to candidates just not declaring any preferences, and also significantly weakens the "your vote won't elect someone you despise" guarantee. So, how to do it? My previous proposal would allow A to approve C (and thus resolve the chicken problem, if they cared to), but would only allow B to approve A. Hmmm... I think I like my fixes better than Forest's, but I'm not sure that there isn't some other possible fix that beats them both. Maybe, only allow C full kingmaker powers between unapproved candidates, if C has already lost? That would still keep A from non-chicken-related meddling... I'll sleep on it. JQ > > I've been thinking that perhaps we should allow candidtes to approve > candidates that they did not rank > ahead of time, as long as they also approve all candidates that they did > rank in that case. > > This would allow a candidate to back down when their bluff was called. > > Would the candidates then just rank themselves in the pre-election public > rankings so that they would > have free reign when it came to approval designations? > > I don't thnk so, because there are other dynamics that make it advantageous > for them to commit to > ranking their significant preferences ahead of time, especially when there > is no chicken standoff, but > even in that case as well. > > Am I misjudging this orI over-looking a worse problem? > > > > - Original Message - > From: Jameson Quinn > Date: Saturday, August 6, 2011 4:04 pm > Subject: Re: [EM] : Chicken problem (was: SODA and the Condorcet > To: fsimm...@pcc.edu > Cc: election-methods@lists.electorama.com > > > 2011/8/6 > > > > > Jan, > > > > > > IRV elects C like all of the other methods if the B faction doesn't > > > truncate. But IRV elects A when the B > > > faction truncates. Of course, with this knowledge, the B > > faction isn't > > > likely to truncate, and as you say C > > > will be elected. > > > > > > The trouble with IRV is that in the other scenario when the B > > faction> truncates sincerely because of > > > detesting both A and C, IRV still elects A instead of B. > > > > > > > Also, if the A faction votes A>B, then B clearly should win, but > > does not > > under IRV. So yes, IRV solves the chicken dilemma, but in so > > doing causes > > other problems. (This same argument, as it happens, works > > against tree-based > > methods.) > > > > I still claim that SODA is the only system I know of that can > > solve the > > chicken dilemma without over-solving it and making other problems. > > > Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
To sum up my point of view suppose that the candidates publicly announce the respective preferences (with levels of support shown): 48 A 27 C>B 25 B We cannot tell from these ballots alone if B is bluffing or if B really despises A and C equally. If the decision is made only on the basis of these ballots, then the right decision for the case when B is bluffing will be the wrong decision for the case when B is not bluffing, so no method that relies on the ballots alone will solve the problem. But if C is allowed to play before B, and C strongly believes that B is bluffing, then C can "bullet." If C is right, then B will approve C also, and C will win. If C is wrong, then A will win. Under actual conditions it is very unlikely that C is going to guess wrongly as to whether or not B is bluffing. SODA allows C to play before B, so the problem is basically solved, as long as B is allowed to approve someone that she did not rank on her ballot, or else as long as there is a very strong incentive for B to rank significant preferences. I've been thinking that perhaps we should allow candidtes to approve candidates that they did not rank ahead of time, as long as they also approve all candidates that they did rank in that case. This would allow a candidate to back down when their bluff was called. Would the candidates then just rank themselves in the pre-election public rankings so that they would have free reign when it came to approval designations? I don't thnk so, because there are other dynamics that make it advantageous for them to commit to ranking their significant preferences ahead of time, especially when there is no chicken standoff, but even in that case as well. Am I misjudging this orI over-looking a worse problem? - Original Message - From: Jameson Quinn Date: Saturday, August 6, 2011 4:04 pm Subject: Re: [EM] : Chicken problem (was: SODA and the Condorcet To: fsimm...@pcc.edu Cc: election-methods@lists.electorama.com > 2011/8/6 > > > Jan, > > > > IRV elects C like all of the other methods if the B faction doesn't > > truncate. But IRV elects A when the B > > faction truncates. Of course, with this knowledge, the B > faction isn't > > likely to truncate, and as you say C > > will be elected. > > > > The trouble with IRV is that in the other scenario when the B > faction> truncates sincerely because of > > detesting both A and C, IRV still elects A instead of B. > > > > Also, if the A faction votes A>B, then B clearly should win, but > does not > under IRV. So yes, IRV solves the chicken dilemma, but in so > doing causes > other problems. (This same argument, as it happens, works > against tree-based > methods.) > > I still claim that SODA is the only system I know of that can > solve the > chicken dilemma without over-solving it and making other problems. > Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
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 an
Re: [EM] : Chicken problem (was: SODA and the Condorcet
> 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
Re: [EM] : Chicken problem (was: SODA and the Condorcet
Sorry if the explanation was not clear enough. A basic tree method with bullet votes indeed has the limitation that you mentioned below (inability to influence the preference order in the competing branch). 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). Building trees could be difficult in some cases. If the clones are from one party, it should not be too difficult to agree that all candidates of one party will be explicit clones. The strongest candidate (and supporters) should accept this because they are more likely to win if he is the strongest candidate of the explicit clone set. The second strongest clone could plan to use a strategy and ask his supporters not to vote for the strongest clone. But maybe saying this aloud in the meeting that discusses the benefits of declaring the candidates of this party as explicit clones would not be an option. Maybe some other explanations could be used. What would be good ones? My guess is that the interest of a party to win the election is so strong that it would be quite natural to use the explicit clone option. If the clones are from two different parties, then the negotiations are one step more difficult. But also here this is just a proposal of cooperation. The idea is probably just to guarantee that the correct wing will win. I have seen also the weaker party of a wing to give up the idea of nominating its own candidate, just to guarantee that the correct wing will win. Having the option of explicit clones would be beneficial to them, and would allow them to nominate their own candidate. And also the stronger party would probably benefit of this agreement to support the strongest of the clones. Tree negotiations were quite complex in the binary tree case that was supposed to solve the free riding problems. But this clone problem is less difficult. Maybe the negotiations are not that difficult. If trees are seen as a natural way to provide a structured set of candidates, then they could be very natural. If they are seen as a special defensive approach to respond to the risk of someone using the chicken strategy, then it could happen that people would fail to nominate explicit clones and someone would try that strategy (but maybe one would learn after one failure). I keep reminding of the benefits of trees because I see them as one very basic approach to eliminating the strategy problems. Trees can be seen also as one approach to fixing the problems that Arrows pointed out (= make the candidates "non-equal") (or not really fix but escape in one quite elegant way). Sorry again if my thoughts appear to be immature and that I didn't name one explicit method as a solution to the problem (or that I misled by referring vaguely just to a tree method (that would by default use bullet votes)). Juho On 7.8.2011, at 17.38, Jameson Quinn wrote: > Please, finish elaborating and describing a method before you claim benefits > for it. I think that building the trees is not as easy or safe as you think. > I know that I myself have been guilty at times of claiming benefits for > something before I'd sat down and really worked it out on paper, and I'm > sorry for it; that's exactly why I know how much of a waste of everyone > else's time it can be. > > JQ > > 2011/8/7 Juho Laatu > I sent also another mail that explained that the basic / simplest tree method > uses bullet votes (and is therefore limited to giving opinions that influence > one branch only), and that trees can be used with richer votes too. In that > case tree methods become hybrids since the tree concept and the idea of > explicit clones can be combined with many different vote counting rules. > > As I described in that mail, trees could be used also just as preprocessing > rules that force the votes to respect the agreed clone sets. After this is > done, those "clone compliant" votes could be consumed by any method (e.g. > some Condocet method could take the "clone compliant" ranked votes as input). > > One could thus indicate which candidate of the competing branch is preferred > by voting e.g. A>B>C (where B and C are the clones of the competing branch, > and A is the only candidate of one's own branch). This vote is "clone > compliant". > > Juho > > > > On 7.8.2011, at 16.48, Jameson Quinn wrote: > >> Like IRV, tree approaches would not allow supporters of candidates from >> other branches to help decide which of the "clones" on the winning branch >> wins. They would also not allow a situation where A likes B but B doesn't >> like A. In both cases, this leads to an IRV-like center-squeeze problem, >> which, especially in one-dimensional scenarios, is quite costly in terms of >> Bayesian Regret. >> >> Perhap
Re: [EM] : Chicken problem (was: SODA and the Condorcet
Please, finish elaborating and describing a method before you claim benefits for it. I think that building the trees is not as easy or safe as you think. I know that I myself have been guilty at times of claiming benefits for something before I'd sat down and really worked it out on paper, and I'm sorry for it; that's exactly why I know how much of a waste of everyone else's time it can be. JQ 2011/8/7 Juho Laatu > I sent also another mail that explained that the basic / simplest tree > method uses bullet votes (and is therefore limited to giving opinions that > influence one branch only), and that trees can be used with richer votes > too. In that case tree methods become hybrids since the tree concept and the > idea of explicit clones can be combined with many different vote counting > rules. > > As I described in that mail, trees could be used also just as preprocessing > rules that force the votes to respect the agreed clone sets. After this is > done, those "clone compliant" votes could be consumed by any method (e.g. > some Condocet method could take the "clone compliant" ranked votes as > input). > > One could thus indicate which candidate of the competing branch is > preferred by voting e.g. A>B>C (where B and C are the clones of the > competing branch, and A is the only candidate of one's own branch). This > vote is "clone compliant". > > Juho > > > > On 7.8.2011, at 16.48, Jameson Quinn wrote: > > Like IRV, tree approaches would not allow supporters of candidates from > other branches to help decide which of the "clones" on the winning branch > wins. They would also not allow a situation where A likes B but B doesn't > like A. In both cases, this leads to an IRV-like center-squeeze problem, > which, especially in one-dimensional scenarios, is quite costly in terms of > Bayesian Regret. > > Perhaps you can think of ways to fix this, but if so, you'll have to be > more specific than "tree methods". > > > > As to SODA; I included my proposed chicken-fix rule in the "optional rules" > section of the SODA page. And it's remarkably unsatisfying. Here is a fix > for what I think is the most significant practical problem scenario in all > of voting theory; and yet half the people would skip that section, half of > the people who read it wouldn't understand why it matters, and half the > people who did wouldn't understand why it works. So, although this is > something I'd love to be able to brag about more, I didn't even include > "fixes the chicken problem" anywhere among the top 15 advantages in the > advantages section. > > Oh well. > > Jameson Quinn > > 2011/8/7 Juho Laatu > >> On 7.8.2011, at 2.04, Jameson Quinn wrote: >> >> >> >> 2011/8/6 >> >>> Jan, >>> >>> IRV elects C like all of the other methods if the B faction doesn't >>> truncate. But IRV elects A when the B >>> faction truncates. Of course, with this knowledge, the B faction isn't >>> likely to truncate, and as you say C >>> will be elected. >>> >>> The trouble with IRV is that in the other scenario when the B faction >>> truncates sincerely because of >>> detesting both A and C, IRV still elects A instead of B. >>> >> >> Also, if the A faction votes A>B, then B clearly should win, but does not >> under IRV. So yes, IRV solves the chicken dilemma, but in so doing causes >> other problems. (This same argument, as it happens, works against tree-based >> methods.) >> >> I still claim that SODA is the only system I know of that can solve the >> chicken dilemma without over-solving it and making other problems. >> >> >> I wouldn't say that trees "over-solve" the problem. The tree approach to >> the chicken problem could be called "explicit clones". That's quite natural. >> Some candidates just announce that they are clones and that they will >> support each others. That sounds like a pretty exact solution, not an >> over-solution. >> >> Do trees "cause other problems" then? They do not allow the voter to >> support one of the clones without supporting the other. But this is exactly >> what the intention of the explicit clone approach is. Also the need to >> declare a branch in the tree could be considered to be a practical problem / >> increased complexity. And the need to identify the clones is an extra task / >> problem. But maybe not really. What other (more serious) problems would the >> trees cause? >> >> Juho >> >> >> >> >> >> >> Election-Methods mailing list - see http://electorama.com/em for list >> info >> >> > > Election-Methods mailing list - see http://electorama.com/em for list info > > > > > Election-Methods mailing list - see http://electorama.com/em for list info > > Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
I sent also another mail that explained that the basic / simplest tree method uses bullet votes (and is therefore limited to giving opinions that influence one branch only), and that trees can be used with richer votes too. In that case tree methods become hybrids since the tree concept and the idea of explicit clones can be combined with many different vote counting rules. As I described in that mail, trees could be used also just as preprocessing rules that force the votes to respect the agreed clone sets. After this is done, those "clone compliant" votes could be consumed by any method (e.g. some Condocet method could take the "clone compliant" ranked votes as input). One could thus indicate which candidate of the competing branch is preferred by voting e.g. A>B>C (where B and C are the clones of the competing branch, and A is the only candidate of one's own branch). This vote is "clone compliant". Juho On 7.8.2011, at 16.48, Jameson Quinn wrote: > Like IRV, tree approaches would not allow supporters of candidates from other > branches to help decide which of the "clones" on the winning branch wins. > They would also not allow a situation where A likes B but B doesn't like A. > In both cases, this leads to an IRV-like center-squeeze problem, which, > especially in one-dimensional scenarios, is quite costly in terms of Bayesian > Regret. > > Perhaps you can think of ways to fix this, but if so, you'll have to be more > specific than "tree methods". > > > > As to SODA; I included my proposed chicken-fix rule in the "optional rules" > section of the SODA page. And it's remarkably unsatisfying. Here is a fix for > what I think is the most significant practical problem scenario in all of > voting theory; and yet half the people would skip that section, half of the > people who read it wouldn't understand why it matters, and half the people > who did wouldn't understand why it works. So, although this is something I'd > love to be able to brag about more, I didn't even include "fixes the chicken > problem" anywhere among the top 15 advantages in the advantages section. > > Oh well. > > Jameson Quinn > > 2011/8/7 Juho Laatu > On 7.8.2011, at 2.04, Jameson Quinn wrote: > >> >> >> 2011/8/6 >> Jan, >> >> IRV elects C like all of the other methods if the B faction doesn't >> truncate. But IRV elects A when the B >> faction truncates. Of course, with this knowledge, the B faction isn't >> likely to truncate, and as you say C >> will be elected. >> >> The trouble with IRV is that in the other scenario when the B faction >> truncates sincerely because of >> detesting both A and C, IRV still elects A instead of B. >> >> Also, if the A faction votes A>B, then B clearly should win, but does not >> under IRV. So yes, IRV solves the chicken dilemma, but in so doing causes >> other problems. (This same argument, as it happens, works against tree-based >> methods.) >> >> I still claim that SODA is the only system I know of that can solve the >> chicken dilemma without over-solving it and making other problems. > > I wouldn't say that trees "over-solve" the problem. The tree approach to the > chicken problem could be called "explicit clones". That's quite natural. Some > candidates just announce that they are clones and that they will support each > others. That sounds like a pretty exact solution, not an over-solution. > > Do trees "cause other problems" then? They do not allow the voter to support > one of the clones without supporting the other. But this is exactly what the > intention of the explicit clone approach is. Also the need to declare a > branch in the tree could be considered to be a practical problem / increased > complexity. And the need to identify the clones is an extra task / problem. > But maybe not really. What other (more serious) problems would the trees > cause? > > Juho > > > > > > > Election-Methods mailing list - see http://electorama.com/em for list info > > > > Election-Methods mailing list - see http://electorama.com/em for list info Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
Like IRV, tree approaches would not allow supporters of candidates from other branches to help decide which of the "clones" on the winning branch wins. They would also not allow a situation where A likes B but B doesn't like A. In both cases, this leads to an IRV-like center-squeeze problem, which, especially in one-dimensional scenarios, is quite costly in terms of Bayesian Regret. Perhaps you can think of ways to fix this, but if so, you'll have to be more specific than "tree methods". As to SODA; I included my proposed chicken-fix rule in the "optional rules" section of the SODA page. And it's remarkably unsatisfying. Here is a fix for what I think is the most significant practical problem scenario in all of voting theory; and yet half the people would skip that section, half of the people who read it wouldn't understand why it matters, and half the people who did wouldn't understand why it works. So, although this is something I'd love to be able to brag about more, I didn't even include "fixes the chicken problem" anywhere among the top 15 advantages in the advantages section. Oh well. Jameson Quinn 2011/8/7 Juho Laatu > On 7.8.2011, at 2.04, Jameson Quinn wrote: > > > > 2011/8/6 > >> Jan, >> >> IRV elects C like all of the other methods if the B faction doesn't >> truncate. But IRV elects A when the B >> faction truncates. Of course, with this knowledge, the B faction isn't >> likely to truncate, and as you say C >> will be elected. >> >> The trouble with IRV is that in the other scenario when the B faction >> truncates sincerely because of >> detesting both A and C, IRV still elects A instead of B. >> > > Also, if the A faction votes A>B, then B clearly should win, but does not > under IRV. So yes, IRV solves the chicken dilemma, but in so doing causes > other problems. (This same argument, as it happens, works against tree-based > methods.) > > I still claim that SODA is the only system I know of that can solve the > chicken dilemma without over-solving it and making other problems. > > > I wouldn't say that trees "over-solve" the problem. The tree approach to > the chicken problem could be called "explicit clones". That's quite natural. > Some candidates just announce that they are clones and that they will > support each others. That sounds like a pretty exact solution, not an > over-solution. > > Do trees "cause other problems" then? They do not allow the voter to > support one of the clones without supporting the other. But this is exactly > what the intention of the explicit clone approach is. Also the need to > declare a branch in the tree could be considered to be a practical problem / > increased complexity. And the need to identify the clones is an extra task / > problem. But maybe not really. What other (more serious) problems would the > trees cause? > > Juho > > > > > > > Election-Methods mailing list - see http://electorama.com/em for list info > > Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
P.S. One can use trees / exact clones also with the vote set that was discussed. > 48 A > 27 C>B > 25 B>C The tree structure could be just a forest here. One tree is A alone. The other tree is (B, C). The idea is that support to B/C means also support to C/B. If I try to vote B>A>C, that would be corrected to B>C>A. If I try to vote B, that would be corrected to B>C (or maybe I did that intentionally, knowing that all the clones will get my vote). The clones will thus always inherit whatever the other clones get. If there is a third clone D, then vote D>A will be corrected / complemented to D>B=C>A. This approach thus sets some explicit limits to how voters are allowed to vote. Or in other words, how the votes to the explicit clones will be transferred / shared between the clones. If the voter forgets that these candidates are explicit clones, their vote can be corrected (rather than rejected). The intention of this mail is just to point out that although the most straight forward approach with trees is to use bullet votes only, one can use the tree structure (and the explicit clone approach) also with more complex votes like ranked votes. Juho On 7.8.2011, at 10.37, Juho Laatu wrote: > On 7.8.2011, at 2.04, Jameson Quinn wrote: > >> >> >> 2011/8/6 >> Jan, >> >> IRV elects C like all of the other methods if the B faction doesn't >> truncate. But IRV elects A when the B >> faction truncates. Of course, with this knowledge, the B faction isn't >> likely to truncate, and as you say C >> will be elected. >> >> The trouble with IRV is that in the other scenario when the B faction >> truncates sincerely because of >> detesting both A and C, IRV still elects A instead of B. >> >> Also, if the A faction votes A>B, then B clearly should win, but does not >> under IRV. So yes, IRV solves the chicken dilemma, but in so doing causes >> other problems. (This same argument, as it happens, works against tree-based >> methods.) >> >> I still claim that SODA is the only system I know of that can solve the >> chicken dilemma without over-solving it and making other problems. > > I wouldn't say that trees "over-solve" the problem. The tree approach to the > chicken problem could be called "explicit clones". That's quite natural. Some > candidates just announce that they are clones and that they will support each > others. That sounds like a pretty exact solution, not an over-solution. > > Do trees "cause other problems" then? They do not allow the voter to support > one of the clones without supporting the other. But this is exactly what the > intention of the explicit clone approach is. Also the need to declare a > branch in the tree could be considered to be a practical problem / increased > complexity. And the need to identify the clones is an extra task / problem. > But maybe not really. What other (more serious) problems would the trees > cause? > > Juho > > > > > > Election-Methods mailing list - see http://electorama.com/em for list info Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
On 7.8.2011, at 2.04, Jameson Quinn wrote: > > > 2011/8/6 > Jan, > > IRV elects C like all of the other methods if the B faction doesn't truncate. > But IRV elects A when the B > faction truncates. Of course, with this knowledge, the B faction isn't > likely to truncate, and as you say C > will be elected. > > The trouble with IRV is that in the other scenario when the B faction > truncates sincerely because of > detesting both A and C, IRV still elects A instead of B. > > Also, if the A faction votes A>B, then B clearly should win, but does not > under IRV. So yes, IRV solves the chicken dilemma, but in so doing causes > other problems. (This same argument, as it happens, works against tree-based > methods.) > > I still claim that SODA is the only system I know of that can solve the > chicken dilemma without over-solving it and making other problems. I wouldn't say that trees "over-solve" the problem. The tree approach to the chicken problem could be called "explicit clones". That's quite natural. Some candidates just announce that they are clones and that they will support each others. That sounds like a pretty exact solution, not an over-solution. Do trees "cause other problems" then? They do not allow the voter to support one of the clones without supporting the other. But this is exactly what the intention of the explicit clone approach is. Also the need to declare a branch in the tree could be considered to be a practical problem / increased complexity. And the need to identify the clones is an extra task / problem. But maybe not really. What other (more serious) problems would the trees cause? Juho Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] : Chicken problem (was: SODA and the Condorcet
2011/8/6 > Jan, > > IRV elects C like all of the other methods if the B faction doesn't > truncate. But IRV elects A when the B > faction truncates. Of course, with this knowledge, the B faction isn't > likely to truncate, and as you say C > will be elected. > > The trouble with IRV is that in the other scenario when the B faction > truncates sincerely because of > detesting both A and C, IRV still elects A instead of B. > Also, if the A faction votes A>B, then B clearly should win, but does not under IRV. So yes, IRV solves the chicken dilemma, but in so doing causes other problems. (This same argument, as it happens, works against tree-based methods.) I still claim that SODA is the only system I know of that can solve the chicken dilemma without over-solving it and making other problems. Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] Chicken problem (was: SODA and the Condorcet criterion)
On 6.8.2011, at 19.40, Jameson Quinn wrote: > More thoughts on the "chicken problem". > > Again, in Forest's version, that's a scenario like: > > 48 A > 27 C>B > 25 B>C > > C is the pairwise champion, but B is motivated to truncate, and C to > retaliate defensively, until A ends up winning. > > In my opinion, scenarios like this make the single most intractable practical > strategy problem in voting theory: > Approval, Range, and median-based systems all suffer directly. > Most winning-vote-like Condorcet systems fall prey, including otherwise-great > systems like Schulze. > Margins systems have no truncation incentive - but as a direct consequence, > they give extremely difficult-to-justify results if the B block truncates; in > fact, they allow a strategic C block to fool the system into thinking it's > seeing this scenarion when actually B and C are mortal enemies. > IRV does relatively well with this scenario - but in return, pays no > attention at all to the second choice of the A voters, which should be > decisive if it exists. > At the other extreme, some systems resolve this problem by forcing strict > rankings from the A voters - but if they really don't have a preference, that > ends up being just statistical noise, and doesn't even necessarily remove the > game-of-chicken incentives if things are balanced right. Moreover, forcing B > and C voters into strict rankings only makes them escalate their truncations > into burials. > > Most of us, when we want to "test" our voting systems with a difficult case, > use a strict-ranking Condorcet cycle of three; the old, standard ABC BCA CAB > scenario. That's nice and simple, but not very realistic. To me, the "game of > chicken" scenario; the resulting Condorcet cycle if B truncates; and related > scenarios that could strategically be made to masquerade as these; are better > practical tests for a voting system. In fact, I'd go so far as to guess that > a real-life Condorcet cycle would be more likely to be the result of playing > chicken than of honest preferences. > > As Forest already explained, SODA, as currently formulated, resolves the game > of chicken — if all votes are delegated. It can do that because games among > finite candidates are much more tractable than those among oceans of voters. > SODA's "sequential trick" would be ridiculous with voters; imagine "Your turn > to vote is on Sunday at 2:35:58 PM." > > In my previous message in this thread (Re: SODA and the Condorcet criterion), > I pointed out that there's still a problem if voters explicitly truncate by > refusing to delegate. But I've been considering this issue, and eventually I > found a solution that I think is simple enough to include in SODA: > > Make all candidate's predeclared rankings into strict rankings by breaking > declared ties in order of the current approval totals when it's their turn to > use their delegated votes. > > So if B voters truncated, candidate A would see that B was headed for a win, > and would have the option to delegate to C. All the truncation would have > accomplished would be to make A into a kingmaker between B and C. Since A > could have had this kingmaker power, if she had wanted it, from the start, > that's not a problem. The only difference between this end-game kingmaker > power of A's, and if she had simply declared a preference from the start, is > that the end-game power could in theory arise no matter which of B or C has > more approvals, whereas an initial preference would only confer kingmaker > power if the preferred candidate ended up with fewer approvals. > > Is this version of SODA really the only system to have a fully-satisfactory > resolution to the chicken problem? Even if it is, is it worth adding this > additional complexity to SODA? Can anyone make a chicken-like scenario which > still stumps this SODA version? (If your scenario has more than 4 candidates, > please use DAC instead of approval to find the SODA order of play.) Or do you > know of a different system which creatively resolves the chicken problem? Remember trees :-). In a tree where B and C form one branch they and their voters are bound to support each others. Juho > > JQ > > 2011/8/5 Jameson Quinn > > > 2011/8/5 > > Jameson, > > as you say, it seems that SODA will always elect a candidate that beats every > other candidate majority > pairwise. If rankings are complete, then all pairwise wins will be by > majority. So at least to the degree > that rankings are complete, SODA satisfies the Condorcet Criterion. > > Also, as I mentioned briefly in my last message under this subject heading, > SODA seems to completely > demolish the "chicken" problem. > > Well almost. See below. > > > To review for other readers, we're talking about the scenario > > 48 A > 27 C>B > 25 B>C > > Candidates B and C form a clone set that pairwise beats A, and in fact C is > the Condorcet Winner, but >
Re: [EM] Chicken problem (was: SODA and the Condorcet criterion)
>>> To review for other readers, we're talking about the scenario >>> >>> 48 A >>> 27 C>B >>> 25 B>C >>> >>> Candidates B and C form a clone set that pairwise beats A, and in fact C >>> is the Condorcet Winner, but >>> under many Condorcet methods, as well as for Range and Approval, there is >>> a large temptation for the >>> 25 B faction to threaten to truncate C, and thereby steal the election >>> from C. Of course C can counter >>> the threat to truncate B, but then A wins. So it is a classical game of >>> "chicken." >>> >>> Some methods like IRV cop out by giving the win to A right off the bat, >>> so there is no game of chicken. Wait a minute! IRV elects C in this scenario, if that is how the voters actually vote, and those are the sincere preferences (A voters have no preference between B and C). Much as I hate to say it, IRV works OK in that scenario. On the other hand, if the A voters prefer B over C, (as in the 2009 Burlington, VT mayoral election, http://scorevoting.net/Burlington.html) IRV ignores the preference and still elects C, which seems to be the wrong choice. Election-Methods mailing list - see http://electorama.com/em for list info
