[EM] Has this idea been considered?

Russ Paielli russ.paielli at gmail.com
Tue Jul 5 01:19:25 PDT 2011


On Mon, Jul 4, 2011 at 10:34 PM, Juho Laatu <juho4880 at yahoo.co.uk> wrote:

> 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).
>
>
After thinking about it a bit more, it seems to me that the method I
proposed at the top of this thread greatly improves on the practicality of
IRV. Not that I'm a big fan of IRV, but it *is* getting a lot of political
support these days, so improving it should be of interest.

First of all, my method is summable, which I consider a huge practical
benefit. Secondly, my method does not require the voter to rank candidates.
That's another huge practical benefit, greatly simplifying equipment
requirements and voter education.

The only "benefit" missing in my proposal compared to IRV is that the voter
cannot specify his own ranking of the candidates but rather must depend on
the candidates own rankings of the other candidates. I hardly consider that
a benefit anyway. I'll bet most voters would rather just leave the ranking
to their preferred candidate anyway. The candidate is likely to have more
time to research the issue, and if you trust the candidate to govern, you
must trust his judgment to some extent to some extent anyway.



> 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.
>

That sounds interesting, but I'm not sure I understand what you mean. Can
you give an example?


>
>
> 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.
>
>
Yeah, it could get a bit weird. Maybe it's not a great combination.

--Russ P.



> 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<http://wiki.electorama.com/wiki/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
>
>
>
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info
>
>


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


More information about the Election-Methods mailing list