[EM] (no subject)

[Forest Simmons]

>
> . 100 . . voter utility or rating . . 0
> ----------------------------------------
> 2 Bush . Perot . . . . . . . . . Clinton
> 1 Perot . . . . . . . . . Bush . Clinton
> 2 Clinton . Perot . . . . . . . . . Bush
>
> I'm aware of the problems with interpersonal comparison of utilities,
> but have a hard time viewing the two cases as equivalent.
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 01 Feb 2005 00:12:44 -0800
> From: Russ Paielli <6049awj02 at sneakemail.com>
> Subject: Re: [EM] Re: simulating an Approval campaign/election
> To: election-methods at electorama.com
> Message-ID: <41FF39FC.7060709 at sneakemail.com>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Rob LeGrand honky1998-at-yahoo.com |EMlist| wrote:
>> Russ Paielli wrote:
>>
>>> Here's what I modeled. I have three candidates only. I randomly
>>> generate votes, with equal probabilities for all six possible
>>> preference orders. The only control variable for each vote is
>>> where the voter "draws the line." In this case, that amounts to
>>> whether or not the voter approves the middle candidate of his
>>> preference list. I initialized the middle-candidate state of each
>>> vote randomly, with an expected mean of half approved and half
>>> not.
>>>
>>> Then I started an iterative simulation of polling cycles and
>>> voter re-evaluation of his vote. I simply assumed that complete
>>> and perfect polling data is available to every voter. Then I have
>>> each voter re-evaluate his approval/disapproval of his middle
>>> candidate based on Forest Simmons elegant strategy rule (special
>>> case for three candidates only): if the voters first choice has
>>> more votes than his third (last) choice, the middle candidate
>>> does not get approved, but if the third choice has more votes
>>> than the first choice, the middle candidate gets approved (if
>>> they are equal I leave it unchanged).
>>
>>
>> You're simulating a DSV (Declared-Strategy Voting) election with
>> Approval.  My current research is on just that topic, though I'm
>> also interested in using DSV with other point-count systems such as
>> plurality, Borda and several others.  That Approval strategy is
>> identical to strategy A in the 3-candidate case.
>
> Interesting. Do you mind if I ask why you are interested in
> Declared-Strategy Voting as opposed to Undeclared-Strategy Voting?
>
> <cut>
>
>>
>>> The first few runs I tried showed rapid convergence within a
>>> cycle or two. Then I wrapped the whole thing in another loop to
>>> simulate many separate elections. I found that most of them
>>> converged within 2 or 3 iterations. However, roughly 1 in 10
>>> fails to converge either to a stable vote count or a stable
>>> winner.
>>
>>
>> 1 in 10 agrees with Merrill's figure: 91.6% of random elections
>> with 3 candidates and 25 voters have a Condorcet winner.  You used
>> more voters, but that would decrease the percentage only very
>> slightly.  Actually, Approval DSV in batch mode using strategy A
>> doesn't always converge even when there's a Condorcet winner, but
>> the examples are quite contrived and require more than 3
>> candidates.  Ballot-by-ballot mode, when the voter order is weakly
>> fair (no voter is shut out for more than 2n steps, say), always
>> finds an equilibrium eventually in my simulations.  There's always
>> a path of changes that leads to an equilibrium, anyway.  When no
>> Condorcet winner exists, strategy A can't lead to an equilibrium
>> because any poll leader can and will be toppled.
>
> Does another strategy converge even if no Condorcet winner exists?
>
>>
>>> So the bottom line is that, even in the simplest, most idealized
>>> case, Approval Voting can be unstable. In such cases, the
>>> ultimate winner would essentially be a random function of when
>>> the election happened to be held. A sort of random lottery. And
>>> many voters would regret their decision.
>>
>>
>> Any voting system for which you can't say the same (like plurality)
>> is easily manipulated and leads to multiple equilibria, some of
>> which may not elect an existing Condorcet winner.  If you find
>
> I assume you mean that plurality can be manipulated by throwing in
> spoilers (e.g., Nader or Perot).
>
> And as for multiple equilibria, it seems to me that all but one of those
> equilibria is practically inaccessable if it requires a third party to
> switch places with one of the two dominant parties.
>
>> convergence more important than competitive elections and sincere
>> voting, you may prefer plurality to Approval.  But I see
>> plurality's many equilibria as false ones that hide much about the
>> electorate's wishes.  Approval only fails to converge when the
>> electorate's wishes are collectively irrational, in a sense, and in
>> that case Approval will eventually cycle only among the sincere
>> Schwartz set.
>>
>> Note that all Condorcet-compliant ranked-ballot voting systems are
>> sometimes manipulable and nonconvergent when there's no Condorcet
>> winner.  Some prefer Condorcet methods to Approval because they see
>> them as harder to manipulate and thus more stable, but I'd rather
>> voters know the rules of the game they're playing.  Alex Small
>> wrote on the ApprovalVoting list:
>>
>>
>>> Legitimacy should come from a transparent connection between the
>>> decisions people make in the voting booth and the final outcome.
>>> If it takes a game theorist to sketch out a flow chart and
>>> explain why voting for A allowed B to win, how much respect will
>>> the system command?
>>>
>>> That's actually one reason why I like Approval Voting:  Although
>>> there are sometimes risky decisions to be made (do I approve my
>>> second choice or only my first?  Do I risk my least favorite
>>> winning or risk hurting my favorite?), at least the cause and
>>> effect is clear.  We won't need a game theorist with a flow chart
>>> to explain things to us the next morning.
>>
>>
>> I second that.  Besides, Approval can make a sincerity guarantee
>> that no ranked-ballot system can:  You should always vote the
>> maximum for your favorite candidate and the minimum for your least
>> favorite.  If all you're given is poll information, you should
>> never vote for B and not for A when you prefer A to B; it never
>> pays to express a false pairwise preference.  I still haven't found
>> another system that has that property of weak sincerity.
>>
>> Anyway, the point is that I think Approval has the best combination
>> of manipulation-resistance, convergence and quality of winners, not
>> to mention simplicity.  A little divergence is worth the better
>> equilibria.
>
> That all seems reasonable to me, but let me outline my evolving view,
> and you can let me know if you think I am on the right track.
>
> You seem to have confirmed my hypothesis that, in the idealized case
> (DSV batch mode), Approval voting almost always converges on the
> Cordorcet winner if one exists, but rarely (never?) converges if one
> does not exist.
>
> If that is true, then it seems to me that Approval may be roughly
> equivalent to Condorcet with random selection of the winner from the
> Smith set. Do you agree with that? If so, has anyone shown that the
> Condorcet winner based on a "good" Condorcet resolution method would at
> least be favored in the random selection process?
>
> That all applies to the idealized case, of course. Once you start adding
> uncertainty and other "real-world" effects, things could change
> dramatically.
>
> --Russ
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 01 Feb 2005 13:18:23 +0100
> From: Markus Schulze <markus.schulze at alumni.tu-berlin.de>
> Subject: Re: MIKE OSSIPOFF vs The list (Re: [EM] I didn't choose to be
> 	the	topic
> To: election-methods at electorama.com, research at ijs.co.nz
> Message-ID: <41FF738F.8883EA3D at alumni.tu-berlin.de>
> Content-Type: text/plain; charset=us-ascii
>
> Dear Craig Carey,
>
> instead of insulting those who don't agree with you,
> you should rather try to convince them.
>
> Example 1:
>
>   38 ABC
>   32 BCA
>   30 CBA
>
>   The IFPP winner is candidate A although a majority of the
>   voters strictly prefers candidate B and candidate C to
>   candidate A. This example demonstrates that IFPP violates
>   e.g. (1) majority for solid coalitions, (2) independence
>   of clones, (3) reversal symmetry, and (4) majority loser.
>
>   My method (aka Schwartz sequential dropping, cloneproof
>   Schwartz sequential dropping, beatpath method, beatpath
>   winner, path voting, path winner, strong immunity from
>   binary arguments) satisfies these criteria.
>
> Example 2:
>
>   Suppose, in example 1, 5 CBA voters didn't go to the polls.
>   Then example 1 had looked as follows:
>
>   38 ABC
>   32 BCA
>   25 CBA
>
>   Now, the IFPP winner is candidate B. This example
>   demonstrates that IFPP violates mono-remove-bottom.
>
>   My method satisfies mono-remove-bottom in the
>   2-, 3- and 4-candidate case.
>
> Example 3:
>
>   Situation 1:
>
>      10 ABCD
>      15 BACD
>      23 CABD
>
>      The quota is 12. A and D are eliminated in the first round,
>      then B beats C.
>
>   Situation 2:
>
>      10 ABCD
>      15 BACD
>      20 CABD
>       3 ACBD
>
>      D is eliminated in the first round. In the second round,
>      the quota is 16 so that A and B are eliminated and C wins.
>
>   This example demonstrates that IFPP violates monotonicity.
>
>   My method satisfies monotonicity.
>
> Please convince me that IFPP was better than my method!
>
> Markus Schulze
>
>
> ------------------------------
>
> Message: 7
> Date: Wed, 02 Feb 2005 02:08:58 +1300
> From: Craig Carey <research at ijs.co.nz>
> Subject: Re: [EM] Craig: I did include ballot-counting code
> To: election-methods-electorama.com at electorama.com
> Message-ID: <5.2.0.9.2.20050202012009.0b727818 at mail.iconz.co.nz>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> MIKE has got me black-listed so, as with Mr Piaelli, I can only reply publicly
> and I can never cut out the step when MIKE makes messages be diluted and
> verbose by expressing false and untrue ideas.
>
> In this matter you were simply in the wrong: it is a dull brainless piece
> on how you hold a great desire to be sensitive to the public's desire to
> "express rankings". What happened between 1992 (you were a CVD member) and
> 1997 (when believer in pairwise comparing) ?. At some point you got
> attached to lies on what it was that voters want. They fill in ballot
> papers with preference lists and hope for a correct set of winners.
>
> Your programming idea, described with the words "express[ed] rankings"
> is totally different from the voters' idea of:
>  (a) ballot paper counts as input, and
>  (b) sets of winners as output.
>
> In 2000 you were a person who would never ever say (privately AND publicly)
> that there was only "one" input to the method function returning a winner
> set: the "collection of ballot papers".
>
> After 4 years of thinking about whether voters in an IRV election only
> create a collection of IRV ballot papers, what you have got for us is the
> total lie, "no", since they instead produced "express[ed] rankings".
>
> Below you say that Russ probably argued that Americans don't actually
> draw antisymmetric matrices onto their ballot papers. We knew that.
>
> Making false claims that a public wants to have a collective preference
> is done to protect one of your beliefs. A public does not "express rankings"
> but instead the falsity of the claim is a stupid strict designed to
> conceal a wrong belief you have.
>
> The public fills in preference lists. What your Python code did was designed
> to do was to trash the public into doing something it never did, sought, or
> has a reason for: create a pretext and deceptive cover story for you. What
> do you want: to believe the lie which is that Condorcet's original thought
> was correct and that there seem to be Comdorcet cycles (those difficult
> to resolve things).
>
> The reason the input stage code was missing, is to help you get attached.
> E.g. some concrete to keep you at the bottom of the water off the edge of
> the wharf, and eventually you would be cataloguing the fish and boots.
>
>
>
> At 2005-02-01 04:03 +0000 Tuesday, MIKE OSSIPOFF wrote:
>>
>> Craig Carey said:
>>
>> What the blazes ?: OSSIPOFF's Python code couldn't even accept ballot paper
>> counts as input. That is what I saw at the Piaelli website.
>>
>> I reply:
>>
>>  Very good point. I agree that it didn't make sense for the Python listing
>> to not have code for receiving and counting rankings. The Python code that
>> I'd written, and Russ had it in its final debugged version, received and
>> counted the raw input to get the pairwise vote totals.
>>
>>  I wanted the program to be usable by anyone who wanted to copy it, and I
>> wanted it to be complete and self-contained. So I included code to receive
>> the rankings from a keyboard, and, from those rankings, to determine the
>> pairwise vote totals, and use those to determine the winner.
>>
>>  Russ passionately insisted no one would want to enter rankings from the
>> kekyboard. One could ask, then, if he thought that people would rather
>> determine the pairwise vote totals without any assistance from a computer
>> program.
>>
>> Sure, for a user who writes programs, that user can write his own
>> ranking-receiving and counting program. But I wanted the program to be
>> accessible to people who weren't inclined to write their own input code. No
>> such luck. Russ left out the keyboard input and count code, leaving a
>> program that had the pairwise vote totals as its inputs--inputs to be
>> obtained by the user however s/he manages to.
>>
>> Of course someone who wants to write their own input code could disregard
>> the keyboard-input code.
>>
>>  By the way, the code to receive the rankings from a keyboard and count
>> them to find the pairwise vote totals was considerably longer than the part
>> that uses those pairwise vote totals for the BeatpathWinner algorithm.
>> That's because, for practical use, it's necessary to give the user a way to
>> correct any keyboard-input errors that s/he makes, and to indicate when s/he
>> has completed each ranking, and when s/he has entered all the rankings. That
>> makes the code considerably longer.
>>
>
>
>
> That is so seemingly dumb, but it is really there to help OSSIPOFF prop up
> some belief. Also the keyboard errors argument seems to be a lie. Though
> OSSIPOFF can't stop a wide range of blunders, it is to be expected that the
> public can't start making errors.
>
> The best solution is for Piaelli to close MIKE's webpage.
>
> We are talking about the format of the input data. I have considered the
> problem and I conclude that computer programmers who develop algorithms,
> will prefer this input:
>
> Table A
> ----------------------------------
>   (1, (1, 0, 0, 0))  % = 1*(A)
>   (2, (1, 2, 0, 0))  % = 2*(AB)
>   (3, (2, 1, 0, 0))  % = 3*(BA)
>   (-4, (3, 2, 1, 0)) % = -4*(CBA)
> ----------------------------------
>
> In instead the algorithm gets IRV ballot counts in a tree stuctured form,
> then the algorithm can be much harder to understand.
>
> OSSIPOFF;s 3rd option, of telling users to sum some of their STV papers,
> is the same as requiring that input data be multiplied by a matrix.
>
> For the input to be standardized, then every one else's algorithm has
> to start off by multiplying by the inverse of MIKE OSSIPOFF's matrix.
>
> The motive for creating the matrix seems to be so muddy and dark, that MIKE
> is only prepared to withhold the motive and mislead about the motive, when
> saying that the public will make mistakes.
>
> Incredibly, MIKE has no words defining the matrix, and no words saying if it
> can be inverted.
>
> He has only got ONE program: surely it might as well set a good example,
> for other programmers to follow.
>
> Voters don't create cycles with their voter. They don't have preferences
> to express, i.e. clues on what the method should do when their vote is
> mixed with other votes. MIKE made a false claim saying voters expressed
> preferences.
>
> The title of this message
>
>    "Re: [EM] Craig: I did include ballot-counting code"
>
> is totally untrue, as I recall, since MIKE never had code to count the
> first column of numbers that is in Table A.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> Election-methods mailing list
> Election-methods at electorama.com
> http://lists.electorama.com/listinfo.cgi/election-methods-electorama.com
>
>
> End of Election-methods Digest, Vol 8, Issue 1
> **********************************************
>