[EM] Dual Dropping method and "Preference Approval" ballot ideas

[Adam Tarr]

Matt wrote:

>The first idea is to combine SSD and RP by using "dropping cost" as the 
>common
>measure and utilizing the outcome of the method that has the lower 
>dropping cost in
>a given election when the two outcomes do not overlap.  I called this 
>combination
>Dual Dropping (DD).  For a description see
>http://sourceforge.net/docman/display_doc.php?docid=9910&group_id=48126
>Why use just SSD or RP when both can be logically combined?  Maybe this
>combination is one of the rare win-win situations that has no down side?  Can
>anyone show an overall disadvantage to making minimizing dropping cost a goal?

This seems like a slick idea, and very in line with the whole motivation 
behind both resolution methods.  The only drawback I can think of is that 
the difference between the two is so small that using one or the other is 
just about as good (and a lot easier to explain).

Can anyone come up with a relatively simple example where RP and SSD 
differ, but RP ends up overturning less winning votes (or winning margins, 
if you like)?  It's pretty hard to come up with a reasonable example where 
the two differ, period.  Here's the simplest I can come up with, and it 
doesn't correspond nicely to any political spectrum I can come up with:

7:A>D>C>B
5:C>B>D>A
3:B>D>C>A
3:A>B>D>C
3:B>A>C>D
1:D>C>B>A

The defeats (from strongest to weakest) are:

B>D and D>C; 14-8 each
A>C and C>B; 13-9 each
B>A; 12-10.

Ranked Pairs throws out the C>B defeat and declares B the winner.  SSD or 
beatpath throws out the B>A defeat and declares A the winner.  Obviously, 
one more voter was overturned by ranked pairs.  I used Rob LeGrand's web 
site to check my work.

If anyone can come up with an example that shows the opposite, i.e. SSD 
overturning more votes, it would be nice to see.  As it stands, all this 
analysis has led me to is the thought that SSD tends to be a little better 
than RP when they differ.

>Another idea is what I call a "Preference Approval" ballot.  All of the 
>approved
>candidate rankings relative to _all_ of the other candidates are counted 
>but the
>rankings of non-approved candidates against each other are not 
>counted.  In other
>words, the voter ranks just rees (rees=his/hers) approved candidates (any 
>ranking
>of non-approved candidate is disregarded).  The ballots are completed (all 
>of the
>non-approved candidates are appended to the ballot as least preferred 
>candidates)
>before being tallied but the tally itself does not increase the vote count 
>of the any of
>the non-approved candidates (no half vote each for being ranked equal with 
>each
>other).  Combining approval and preference this way addresses the "comparing
>apples with oranges" problem of preference ballots giving equal weight to 
>approved
>and non-approved candidates.  Unfortunately this may also provide more 
>strategic
>voting opportunity than either approval or preference balloting alone.

What you are proposing is basically a Condorcet voting system where we ask 
the voters "kindly only vote for candidates you approve of".  Obviously 
this can't really be enforced, so it has pretty limited value.  Other 
people have proposed allowing voters to put an "approval cutoff" on the 
ballot, and using the approval counts as a tie-breaker in the case of a 
cyclic ambiguity.  The problem with this is that it can introduce a lot of 
strategy.

It basically breaks down this way: if the approval winner is the same as 
the Condorcet winner, then there's not much strategy for the voters.  But 
if they differ, then the supporters of the approval winner have a lot of 
motivation to try to vote insincerely and introduce a cyclic ambiguity, 
while the supporters of the Condorcet winner have a lot of motivation to 
disapprove the approval winner.

Bottom line: since things only work out well when the approval ballots come 
up the same as the Condorcet ballots, why bother with the approval ballots 
at all?  Better to use a Condorcet method that minimizes strategy in a more 
general case.

-Adam


----
For more information about this list (subscribe, unsubscribe, FAQ, etc), 
please see http://www.eskimo.com/~robla/em