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

[Jameson Quinn]

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 <juho4880 at yahoo.co.uk>

> 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 <juho4880 at yahoo.co.uk>
>
>> On 7.8.2011, at 2.04, Jameson Quinn wrote:
>>
>>
>>
>> 2011/8/6 <fsimmons at pcc.edu>
>>
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20110807/58321a25/attachment-0004.htm>