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 <[email protected]> > 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 <[email protected]> > >> On 7.8.2011, at 2.04, Jameson Quinn wrote: >> >> >> >> 2011/8/6 <[email protected]> >> >>> 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
