[EM] Amalgamation details, hijacking, and free-riding

[Jameson Quinn]

2011/8/3 <fsimmons at pcc.edu>

> So if the true preferences are
>
> 20  A>B
> 45  C>?
> 35  (something else),
>
> the C supporters could spare 21 voters to vote A>C so that the amalgamated
> factions would become
>
> 41 A>C
> 24 C>?
> 35 (something else) .
>
> I can see where it is possible for such a move to payoff, but it seems
> fairly innocuos compared to other
> strategy problems like burial, compromising, chicken, etc.
>

Not to me. I would be livid to find out my vote had been hijacked. All the
other strategies you mention at least use a voter's own vote.


>
> In any case, it can only be a problem in methods that forget the ratings
> after the amalgamation and use
> only the rankings (like DSC), because when two candidates are rated closely
> a small "hijacking" effort
> could tip the balance and reverse the ranking of the two candidates in
> question.
>
> On the "free rider" problem of some PR methods, what do you think about the
> following?
>
> Because of its "free riding problem" Plurality is a fairly decent PR method
> in a perfect information
> setting, as long as voters agree to randomize in order to take advantage of
> the free riding effect.  For
> example in a three winner election where the voter preferences are
>
> 60 A1>A2
> 25 B
> 15 C
>
> If the A supporters agreed to toss coins and vote A! or A2 in the case of
> heads or tails, respectively,
> then the winning slate would be {A1, A2, B}, the best possible outcome in
> this case.
>
> So, in at least one PR method, the "free-riding" possibilities are
> essential for the fairness of the method.
>
> In fact, that is the basic principle of Asset voting (for PR); the
> candidates share their assets so that
> none will be wasted unnecessarily.  Whether the voters or the candidates do
> the redistribution doesn't
> natter in the perfect info case.
>
> In the zero info case, free-riding doesn't work, so it can neither harm nor
> help.
>
> So, I don't worry too much about it.
>

Free riding in some form is inevitable in a good system. (That is, any
system which avoids free riding entirely would be horribly warped by that
necessity). So it's a problem to be managed, not avoided. Still, to me it is
worth some thought. I'm not so much worried about successful free
riding/vote management, as about the pernicious effects of failed
strategies. A system should aim to be "good enough" that most voters do not
bother voting dishonestly in an attempt at free riding. STV is not always
"good enough" in that sense, but I think that there are systems which are
better. In the end, it's an empirical question.

JQ



>
> From: Jameson Quinn
>
> > OK, that's what I thought. So, candidate hijacking does not work
> > for any
> > amalgamated "ballot blind" method, that is, a method which
> > forgets which
> > rating came from which ballot. However, on a non-ballot-blind system,
> > including the ranking-based DSC which was the next step in your
> > SODA-inspired "sequential play" method, it can work. Basically,
> > it involves
> > finding a faction a bit smaller than yours, and ranking its favorite
> > candidate first. Since your faction is larger, you will be able
> > to set the
> > ranking of the remaining candidates, and you will gain the
> > ballot weight of
> > the smaller faction. Of course, you must be sure that the "false flag"
> > candidate does not win. This is similar to Wodall free riding in PR.
> >
> > JQ
> >
> > 2011/8/1
> >
> > > To amalgamate factions so that there is at most one faction
> > per candidate X
> > > (in the context of range
> > > style ballots) take a weighted average of all of the ballots
> > that give X
> > > top rating, where each ballot has
> > > weight equal to one over the number of candidates rated equal
> > top on that
> > > ballot. The total weight of the
> > > resulting "faction rating vector" for candidate X is the sum
> > of the weights
> > > that that were used for the
> > > weighted average.
> > >
> > > Note that these faction rating vectors are efficiently
> > summable. A running
> > > sum (together with its weight)
> > > is kept for each candidate. Any single ballot is incorporated
> > by taking a
> > > weighted average of the running
> > > sum and the ballot, where the respective weights are those
> > mentioned above.
> > > For the running sum it is
> > > the running sum weight. For the ballot it is zero if the
> > candidate is not
> > > rated top, and 1/k if it is rated top
> > > with (k-1) other candidates..
> > >
> > > To combine two running sums for the same candidate take a
> > weighted average
> > > of the two using the
> > > running sum weights, and then add these weights together to
> > get the
> > > combined running sum weight.
> > >
> > > If you multiply each faction rating vector by its weight and
> > add up all
> > > such products, you get the vector of
> > > range totals.
> > >
> > > Of course Range as a method is summable more efficiently without
> > > amalgamating factions, but other
> > > non-summable methods, when willing to accept amalgamated
> > factions, thereby
> > > become summable.
> > >
> > > So, for example, we can make a summable form of Dodgson:
> > >
> > > (1) Use ratings instead of rankings.
> > >
> > > (2) amalgamate the factions.
> > >
> > > (3) let each candidate (with help from advisors) propose a
> > modification of
> > > the ballots that will created a
> > > Condorcet Winner.
> > >
> > > (4) the CW that is created with the least total modification
> > is the winner.
> > >
> > > Modifications are measured by how much they change the ratings
> > on how many
> > > ballots.
> > >
> > > For example if you change X's rating by .27 on 10 of the 537
> > ballots of one
> > > faction, and by .32 on 15
> > > ballots from another faction, then the total modification is
> > 2.7 + 4.8 =
> > > 7.5
> > >
> > > The reason for the competition is that otherwise the method
> > would be
> > > NP-complete.
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20110803/8ec387b8/attachment-0004.htm>