Re: [EM] Has this idea been considered?
On 6.7.2011, at 6.42, Russ Paielli wrote:
On Tue, Jul 5, 2011 at 2:14 AM, Juho Laatu juho4...@yahoo.co.uk wrote:
On 5.7.2011, at 11.19, Russ Paielli wrote:
If one wants to simplify the inheritance rules even more then we might end
up using a tree method (I seem to mention it in every mail I send:). In that
approach there is no risk of having loops in the candidate transfer order.
Votes would be counted right away for each branch, and the candidate of the
largest brach of the largest branch of the ... would win.
That sounds interesting, but I'm not sure I understand what you mean. Can
you give an example?
Here's one example.
Tree of candidates + number of personal votes + sum of votes of candidates of
each branch:
Branch1 (13)
Branch1.1 (7)
A (4)
B (3)
Branch1.2 (6)
C (6)
Branch2 (18)
Branch2.1 (12)
D (5)
E (7)
Branch2.2 (5)
F (3)
G (2)
Branch2.3 (1)
H (1)
- Branch2 has more votes than Branch1 = Branch2 wins
- Branch2.1 has more votes than Branch2.2 and Branch2.3 = Branch2.1 wins
- candidate E has more votes than candidate D = candidate E wins
The tree approach thus forces the order of transfer to be non-cyclic. The
transfer order of candidate E is E D {F, G, H}.
The tree format can be printed on paper and it is easy to grasp. The ballot
sheet may also follow the same tree format. Branches may have names (e.g.
party names) or be unnamed. Left wing parties could join forces under one
branch. Candidates of one party could be divided in smaller groups. Or maybe
the branches have no party names and party affiliations, maybe just
descriptive names, maybe no branch names at all.
Thanks for the example, but I don't understand. Who decides what the branches
are, and based on what? Why is E transferring votes if E has the most votes?
And what are the counts after each transfer? Sorry if those are dumb
questions.
Maybe the method is simpler than you expected. It could be as well described as
a list based method where the parties can be internally split in smaller
groupings (or they can join also together in larger groups). My references to
vote transfers are just to explain how this method relates to methods that use
transfers in the vote counting process. The votes that E transfers are
actually not taken away from him but counted both for him and all the branches
that contain him (sorry about using such confusing terms). In this method one
can in a way transfer all the votes right away to the groups that some
candidate is part of. We thus just count the votes of each party / grouping
(i.e. sum up the votes to the candidates of that party). Votes are not
transferred (or summed up) to other candidates but to the branches of the
tree (= parties, groups) that represent all the candidates within them. The
formal vote counting rules will probably not use term transfer at all (maybe
sum instead).
The numbers in the example show the final counts, where the votes (that were
all given to the candidates) have been summed up. The vote counting rule starts
simply the biggest party gets the only seat. In this example Branch2 (=
party2 or wing2) is bigger than Branch1, and therefore the only available seat
goes to that party. (Note that the tree method could be used as well in
multi-member elections.) Then that single seat will be allocated within Branch1
to the biggest of the party internal branches, i.e. Branch2.1, and then to E
that has more votes than D.
The branches will be decided by the parties or whatever associations or
groupings the candidates and their supporters will form. Let's say that
Branch1.1 and Branch 1.2 are two left wing parties that nominated their
candidates ( {A, B} and {C} ) themselves and then decided to joins forces and
form a joint branch (Branch1) to beat the right wing candidates (that was not
enough though since the right wing parties did the same thing and got more
votes). Or in a two-party country like the U.S. this example would of course be
Branch1=Democrats, Branch2=Republicans, and then the candidates of these
parties would form some groups within that party. Branch2.1. could contain two
similar minded candidates from California. They joined together since they
understood that if they would both run alone, they would probably be spoilers
to each others and they could not win. Party internal groupings could thus be
arranged by the party itself or by the individual candidates that form the
sub-branch. It would depend on the election rules who is will formally nominate
such groups (party vs. already nominated candidates vs. whatever group of
candidates).
From strategic point of view it makes sense to form sub-brances (all the way to
a binary tree). Within Branch2 sub-branches Branch2.2 and Branch2.3 could have
also joined forces together (and add one extra level of hierarchy in the tree)
in
Re: [EM] SODA clarification
2011/7/6 Andy Jennings electi...@jenningsstory.com Jameson, I have become confused about one point of operation in SODA. Take this scenario: 35 ABC 34 BCA 31 CAB If A delegates to A,B then does B have 69 votes he can delegate to B,C or does he have only 34 he can play with? In other words, can votes delegated from one candidate to another be re-delegated to a third candidate? B has 34. Delegable votes are only bullet votes. In fact, a real SODA scenario would probably be more like: 25 A (B) 5 A,X 5 A,B 26 B (C) 4 B,X 4 B, C 29 C (A) 1 C,X 1 C,A Initial totals: 36A, 39B, 35C Delegable: 25A, 26B, 29C Note that in this example, C has the most delegable votes and would decide delegation first, even though B has the most total initial votes. In this case - a Condorcet cycle - the result would be the same no matter who delegates first, as long as all candidates use correct strategy. But there are cases where it wouldn't be: 25: Left (X) 15: Left, Center 5: Left, Right 25: Center (Right) 30: Right (Center) The candidate Left has not declared any delegable preferences, but the left voters clearly tend to prefer Center over Right. Center is the Condorcet winner, but Right would get the chance to delegate before Center, and thus would be the strategic winner under SODA. If delegation order went in order of total votes instead of delegable votes, Center would win. Hmm... now that I look at this scenario in black and white, I'm starting to think that delegation order should be in order of total, not delegable, votes. Not that there isn't a case to be made for Right in this election; if Center were really a better result, then they should get either Left's delegation or more delegable votes from the nominally voters who chose [Left, Center] here. This argument like FairVote's handwaving arguments about strength of support - which is not necessarily invalid just because it's imprecise and easy to reduce ad absurdem. But... I think that having this scenario go to Right puts too much of a burden of strategic calculation on the [Left, Center] voters. So, yet another adjustment to SODA, I think. Delegation choice goes in descending order of total votes; the person with the most total votes gets the first move. If my grounded intuition is correct, this should not matter when there's a 3-way cycle, only when there's a pairwise champion (CW). Hopefully this will be the last time I have to adjust SODA. Also note that all the adjustments so far have been minor tweaks; any of the versions so far would work well, though I believe they have been steadily improving. Current rules, as always, are at http://wiki.electorama.com/wiki/Simple_Optionally-Delegated_Approval JQ I looked at the wiki and still am unclear on this. I still have the original SODA proposal in my head (where votes could not be delegated multiple times) and I can't remember if we've changed this detail at some point. Thanks, Andy On Tue, Jul 5, 2011 at 12:39 PM, Jameson Quinn jameson.qu...@gmail.comwrote: Russ, you said that SODA was too complicated. In my prior message, I responded by saying that it was actually pretty simple. But thanks for your feedback; I realize that the SODA page was not conveying that simplicity well. I've changed the procedure there from 8 individual steps to 4 steps - simple one-sentence overviews - with the details in sub-steps. Of these 4 steps, only step 1 is not in your proposal. And the whole of step 4 is just three words. The procedure is exactly the same, but I hope that this versionhttp://wiki.electorama.com/wiki/Simple_Optionally-Delegated_Approval#Proceduredoes a better job of communicating the purpose and underlying simplicity of the system. Thanks, Jameson 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] Has this idea been considered?
On 7/22/64 2:59 PM, Russ Paielli wrote: ...I eventually realized I was kidding myself to think that those schemes will ever see the light of day in major public elections. What is the limit of complexity that the general public will accept on a large scale? I don't know, but I have my doubts that anything beyond simple Approval will ever pass muster -- and even that will be a hard sell. My experience with CIVS suggests that ranking choices is perfectly comprehensible to ordinary people. There have been more than 3,000 elections run using CIVS, and more than 60,000 votes cast. These are not technically savvy voters for the most part. To pick a few groups rather arbitrarily, CIVS is being used daily by plant fanciers, sports teams, book clubs, music lovers, prom organizers, beer drinkers, fraternities, church groups, PBeM gamers, and families naming pets and (!) children. If anything, to me ranking choices seems easier than Approval, because the voter doesn't have to think about where to draw the approve/disapprove cutoff, which I fear also encourages voters to think strategically. -- Andrew attachment: andru.vcf Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] SODA
Yes, you are right!
Now I would like to suggest a way to make this method clone proof:
The key is to use the solid coalition structure of the factions to determine
the sequential order of play
(i.e. delegation), from largest coalition to smallest. I believe that
completely solves the problem.
Here's an example where A got split into A1 and A2.
16 A1A2B
12 A2A1B
24 BA1=A2
48 C
Even though the C faction is the biggest faction, and the A1 faction is the
second smallest faction,
candidate A1 is the first to delegate in this new order. Here's why:
The largest coaltion (besides the entire set of factions) is the coalition made
up of the set of factions
{A1, A2, B} with 52 percent of the electorate (versus 48 percent for the
coalition {C faction}). Within the
large coalition, the largest subcoalition is {A1, A2} with 26 percent of the
entire electorate (versus 24
percent for the coalition {B faction}).
Within this subcoalition the larger of the two subcoalitions is the A1 faction.
Since there are no further
subcoalitions, candidate A1 plays first.
Then A2 goes next, because we finish the {A1, A2} subcoalition (which was
larger than the B
subcoalition) before letting B play. C goes last because at the root of the
coalition tree C was the branch
on the smaller side.
In sum the order of play is A1, A2, B, C.
The process of deciding the order of play can be summarized more succinctly
with a recursive
description:
Start at the root of the coalition tree, and recursively order the leaves (i.e.
the individual factions) of the
respective branches in descending order of the branch sizes.
I think that in selling the method, we can make the precise sequential order a
technical detail easily
glossed over by simply referring to it as the natural clone independent
sequential order, or something
like that.
- Original Message -
From: Jameson Quinn
Date: Tuesday, July 5, 2011 7:25 pm
Subject: Re: [EM] SODA
To: fsimm...@pcc.edu
Cc: election-methods@lists.electorama.com
2011/7/5, fsimm...@pcc.edu :
I thought that A was required to make her approvals consistent
with her
ordering, i.e. to approve
everybody ranked above her cutoff. Doesn't that mean she is
required to
approve herself?
Maybe I'm thinking of an older version of SODA.
I hope you are right that there is nothing to fix.
Let's do this slowly. Here's the scenario:
34 ABC
35 BCA
31 CAB,
B delegates first. B delegates to B,C. Totals are now C 66, B35, A34.
A's turn. If A does not delegate, C will be winning when it
comes to
C's turn, and so C will not delegate. So A delegates to A,B. Totals
are now B69, C66, A34. C's turn. C is unhappy with B and so delegates
to C,A - but it's not enough. Final totals are B69, C66, A65.
I believe that the correct strategy for any combination of delegable
and undelegable votes (including minor, non-Smith candidates) in a
3-candidate Smith set is always for everyone to approve two
members of
the Smith set if they care between the bottom two. This gives
the same
result as minimax and most Condorcet methods. I haven't proven this,
and I don't have a general understanding of strategy for larger Smith
sets.
It is possible, when there are 3 or more near-clones A1, A2, A3...
running against a different candidate B with almost 50% - that
is, B
can beat any combination of fewer than all the A's, and B has no
preference among the A's - that the true Condorcet winner among the
A's is subject to center squeeze, and the A's are forced to throw
their support to whichever of them has the most delegable votes, in
order to prevent B from winning. The upshot is that SODA, even
assuming candidates are honest in their pre-vote rankings and
strategic in their delegation, does not pass the Condorcet criterion,
but does pass the majority Condorcet criterion (that is, a pairwise
winner always wins if each of the pairwise wins constitutes a
majority). But I can't find any nonmonotonic scenario pairs, so this
Plurality within the faction is the worst result I can find. I think
that it's both unlikely and, really, not so bad.
JQ
- Original Message -
From: Jameson Quinn
Date: Tuesday, July 5, 2011 1:07 pm
Subject: Re: [EM] SODA
To: fsimm...@pcc.edu
Cc: election-methods@lists.electorama.com
2011/7/5
Jameson suggested that the SODA candidates make their approval
decisions sequentially instead of
simultaneously.
The problem with this is that if a winning candidate moves to
first place
in the sequence by an increase
in support, she may become a losing candidate:
Assume sincere preferences are
35 ABC
34 BCA
31 CAB
If approval decisions are made in descending order of faction
size A, B, C,
then B wins.
If B gains more support so that the totals become
34 ABC
35 BCA
31 CAB,
the sequential order becomes B, A, C, and the winner will
be C.
Re: [EM] SODA
2011/7/6 fsimm...@pcc.edu By the way, when the delegations are done sequentially, the optimum strategy for each player is (generically) deterministic. No mixed strategies are needed to get optimum game theoretic results. Yes, that's the point. Because of this, a DSV (Delegated Strategy Voting) version would give the same result as rational players. Yes, but I don't recommend actually using the DSV version. Having candidates actually decide is a safeguard against candidates using dishonest strategy in the ranking - the only phase when dishonest strategy is possible. Therefore, we finally have a monotone, clone free, DSV that takes rankings as input, and puts out rationally determined approval ballots. Well, you'd have to impute the most popular ranking among a candidate's voters to the candidate, and either use some direct approval strategy or make fake candidates for all other rankings among a candidate's voters... and that breaks the nice symmetry of the method somewhat, but none of it should break the monotonicity or the clone-freeness. This should be of interest to Rob LeGrand, who has done a lot of study on DSV methods that turn rankings into approval ballots. Furthermore, this gives us a way of generating Yee diagrams for SODA, i.e. to make Yee diagrams for Approval without just assuming that Approval will always find the Condorcet winner. Yes, that is true, with the caveats above. JQ Election-Methods mailing list - see http://electorama.com/em for list info
Re: [EM] SODA
Therefore, we finally have a monotone, clone free, DSV that takes rankings as input, and puts out rationally determined approval ballots. Well, you'd have to impute the most popular ranking among a candidate'svoters to the candidate, and either use some direct approval strategy or make fake candidates for all other rankings among a candidate's voters...and that breaks the nice symmetry of the method somewhat, but none of it should break the monotonicity or the clone-freeness. Actually, the same coalition tree technique would work for as many factions as desired, outputing a (potentially) different approval ballot for each faction, even when several different factions have the same favorite. Of course, with too many factions, the optimal strategy computation would be intractable. Let's see how it would work on the simple example 45 BCA. 15 CBA 30 ACB 10 CAB The coalition tree is (45BCA /\15CBA)/root\(30ACB /\ 10CAB). I have ordered the factions so that traversing the tree in its preorder gives the correct sequence. At the root node the left branch accounts for 60 percent of the ballots, while the right branch accounts for 40 percent, so the left branch is rightfully traversed first (as in a preorder traversal), etc. Since there are two approval cutoff possibilities for each faction, there are sixteen possible cutoff configurations. I'm not going to list them all, but (if I am not grossly mistaken) the (essentially) unique optimal solution is 45B, 15C, 30 AC, 10 C, which gives approval totals for A, B, and C as 30, 45, and 55, respectively. I say essentially because it makes no difference whether the BCA faction approves C or not. In the long run any of Rob LeGrand's DSV (Designated Strategy Voting) methods (whether batch or sequential, whether strategy A or not) would yield approvals in the same proportion for this particular example.. Our coalition tree based method uses the same solid coalition structure as Woodall's Descending Solid Coalition (DSC) method, but soon parts company with DSC, although in this particular example it yields the same result, namely that C wins. Election-Methods mailing list - see http://electorama.com/em for list info
