[EM] Has this idea been considered?

[Juho Laatu]

On 5.7.2011, at 3.09, Russ Paielli wrote:

> Thanks for the feedback, Jameson. After thinking about it a bit, I realized that the method I proposed probably suffers from strategy problems similar to IRV. But at least it avoids the summability problem of IRV, which I consider a major defect.

I agree that if IRV is interesting then also this method is. Some IRV related problems remain but you will get summability, clear declarations of candidate preferences, very simple voting and ability to handle easily large number of candidates. You could say that this method is also an improvement of TTR (similar voting, but has ability to pick the winner in one round only, maybe smaller spoiler problem).

If people don't like the preference list given by their favourite candidate, one could nominate additional fake candidates to offer additional preference lists. If the preference list of candidate A is A>B>C, then thee could be an additional (weaker) candidate A1 whose preference order would be A1>A>C>B.

One possible extension would be to allow candidates that are afraid that they would be spoilers (that reduce the votes of a stronger favourite candidate too much so that he will be eliminated too early) to transfer their votes right away. The preference list could have a cutoff. Preference list A>B>C>>D>E (of candidate A) would be interpreted so that votes to A would be added right away also to the score of B and C (but not D and E). If A gets transferred votes from some other candidates, they will be transferred further (to candidates not mentioned above cutoff in the original transfer list) only after A has been eliminated. (One could use this trick also in regular IRV.)

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.

> 
> OK, here's another proposal. Same thing I proposed at the top of this thread, except that voters can vote for more than one candidate, as in Approval Voting. How does that stack up?

You should define that method a bit more in detail. I started wondering if it would allow candidate X to win if he asked also 100 of his friends to take part in the election and transfer their votes to him.

Juho



> 
> By the way, I took a look at SODA, and I must tell you that I don't consider it a "practical reform proposal." It's way too complicated to ever be adopted for major public elections. The method I just proposed is already pushing the limit for complexity, and it is much simpler than SODA.
> 
> Regards,
> Russ P.
> 
> 
> On Mon, Jul 4, 2011 at 1:10 PM, Jameson Quinn <jameson.quinn at gmail.com> wrote:
> A system based purely on candidates freely transferring their votes until a majority (or Droop quota) is reached is called Asset voting. I believe that Asset voting is a good system, though there are certainly those who'd disagree. It is also possible - and I'd say desirable - to combine aspects of Asset with other systems productively. One such proposal, SODA, is currently my favorite practical reform proposal, something I have real hopes for. So I'd certainly say you have (reinvented) some good ideas here.
> 
> With that said, I can see a couple of problems with this system right off. First off, bottom-up elimination is probably the worst feature of IRV, because there is a fairly broad range of situations where it leads inevitably to eliminating a centrist and electing an extremist, in a way that can clearly be criticized as "spoiled" (the centrist would have won pairwise) and "nonmonotonic" (votes shifting to the winner can cause them to lose). Secondly, a voter has no power to ensure that their vote is not transferred in a way they do not approve of. This second disadvantage compounds with the first, because a minority bloc will be eliminated early, and their votes transferred more than once before the final result.
> 
> Cheers, 
> Jameson
> 
> 2011/7/4 Russ Paielli <russ.paielli at gmail.com>
> Hello,
> 
> I was somewhat active on this mailing list for a short time several years ago. How is everyone doing?
> 
> I have an idea for a single-winner election method, and it seems like a good one to me. I'd like to know if it has been considered before and, if so, what the problems are with it, if any. Here's how it works:
> 
> The mechanics of casting a ballot are identical to what we do now (in the US anyway). Each voter simply votes for one candidate. After the votes are counted, the last-place candidate transfers his or her votes to the candidate of his or her choice. Then the next-to-last candidate does the same thing, and so on, until one candidate has a majority.
> 
> The transfer of votes at the close of polling could be automated as follows. Weeks before the election, each candidate constructs a ranked list of his or her preferences for the other candidates. The resulting preference matrix could (should?) be published for the voters to see in advance. The bottom candidate at each round of transfers would then have his or her votes automatically transferred to the top remaining candidate in his or her preference list.
> 
> The transfer of votes from the bottom finisher in each round resembles IRV, but note that this method is "summable" -- a major advantage over IRV, eliminating the need to maintain a record of each and every vote cast. I think it may also have other major strategy-deterring advantages over IRV. What do you think? Thanks.
> 
> Russ P.
> 
> -- 
> http://RussP.us
> 
> 
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info
> 
> 
> 
> 
> 
> -- 
> http://RussP.us
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20110705/43aec079/attachment-0004.htm>