[EM] Why Clone Independence?
Kristofer Munsterhjelm
km_elmet at t-online.de
Tue Jan 24 13:32:58 PST 2023
On 24.01.2023 22:04, Forest Simmons wrote:
> Somebody needs to talk about this ... I'm not sure I'm the right person
> ... but here goes ...
If I were to answer the question in simple terms, I would put it like this:
- If there's a clone winner problem, then candidates may be incentivized
to drop out of the race, which is a bad thing.
- If there's a clone loser problem, then the election can possibly go to
whatever faction manages to muster up enough candidates to spam the
ballot, which is worse.
- If there's a crowding problem, then the method generally behaves
chaotically; it's a sort of IIA failure.
When we aim for clone independence, we're implicitly assuming that the
clone independence will in some way be robust; i.e. that a lack of clone
winner problems implies no incentive to exit, and a lack of clone loser
implies no incentive to entry.
James Green-Armytage showed that this implication doesn't hold for IRV.
Conversely, his research suggests that although minmax fails clone
dependence, it doesn't produce a severe nomination incentive in
practice, in either direction.
So ideally we'd be designing the methods to lack nomination incentive,
instead of designing them to pass a criterion that only implies such a
lack if it generalizes properly. But doing the former is incredibly
messy - it's both hard to verify and hard to design. Hence the stand-in
of clone independence.
And usually it works! Ranked Pairs and Schulze have very low nomination
incentive. But not always.
I would say that it's not so much that clone winner is linked to
compromising and clone loser to burial, as that they're linked to
nomination incentive. For instance, with enough candidates in impartial
culture, Ranked Pairs and Schulze are plenty susceptible to burial, even
though they're cloneproof.
(Though perhaps there is a more clear relation in say, a spatial model.
I don't know as I haven't checked.)
-km
More information about the Election-Methods
mailing list