[EM] Mono-switch-Plump criterion compliance claims corrected

Wed Oct 26 05:46:09 PDT 2016

Can you please post an explanation of "Margins-Sorted Losing Votes (erw)
Elimination" on electowiki?

2016-10-26 0:08 GMT-04:00 C.Benham <cbenham at adam.com.au>:

> Forest has pointed out that my supposed example of  Approval Sorted
> Margins failing mono-switch-plump is nonsense.
>
> So (at least for the time being) I am not able to show that Approval
> Sorted Margins fails the mono-switch-plump criterion.
>
> (BTW I am still very happy with the Margins-Sorted Losing Votes (erw)
> Elimination method.)
>
> Chris Benham
>
>
>
> On 10/24/2016 10:28 PM, C.Benham wrote:
>
> The Mono-switch-plump criterion is much stronger than I previously
> thought, and is probably simply incompatible with the
> Condorcet criterion.
>
> I used to think that its met by two of my favourite Condorcet methods,
> Margins-Sorted Losing Votes (erw) Elimination (equivalent in the 3
> candidate case
> to the "MMLV(erw)M" I discuss in the May 2014 post) and Approval Sorted
> Margins.  Consider this election under MSLVerwE :
>
> 40: A
> 29: C>A
> 03: B
> 28: B>C
>
> A>B 69-31,    B>C 31-29,    C>A 57-40.   LV(erw) scores:  A40 > B31 >
> C29.  No adjacent pair is out-of-order pairwise, so MSLV(erw)E elects A.
>
> But if we switch the 3 B plumping ballots to A then C becomes the
> Condorcet winner (C>B 29-28,  C>A 57-43).
>
> 43: A
> 29: C>A
> 28: B>C
>
> And now this election under Approval Sorted Margins:
>
> 30: C
> 04: C>A
> 33: A>B
> 32: B
>
> A>B 37-32,   B>C 64-34,   C>A 34-33.    (Implicit) Approval scores: B64 >
> A37 > C34.  The adjacent pair with the smallest (absolute margin) difference
> in their scores (A > C) is pairwise out of order so we flip that to give B
> > C > A.  Now neither adjacent pair is pairwise out-of-order, so the order
> is
> final and so Margins Sorted Approval elects B.
>
> But if we switch two of the 32 B plumping ballots to A then A becomes the
> Condorcet winner (A>B 39-34,  A>C 35-34).
>
> 30: C
> 04: C>A
> 33: A>B
> 02: A
> 30: B
>
> I doubt that IBIFA meets the criterion.
>
> But I remain sure that it's met by Bucklin (and similar methods like MTA
> and MCA and QLTD).
>
> Chris Benham
>
> On 11 May 2014  Chris Benham  posted  to EM:
>
>
>  Mono-switch-plump:
>
> *The probability of candidate X winning must not be reduced if one or more
> ballots that
> plump for any not-X  are replaced by an equal number of ballots that plump
> for X.*
>
>
> Previously I showed that this is failed by the following methods:
>
> Schulze (aka Beatpath), Ranked Pairs, River, MinMax (all equivalent with 3
> candidates) if they use Winning Votes to weigh pairwise defeats.
>
> IRV and the Condorcet methods based on IRV  (such as Benham and Woodall)
>
> Total Approval Chain Climbing.
>
> I claim that it is met by  Margins,  any positional method, IBIFA, Bucklin
> and Bucklin-like methods like Median Ratings and MCA and MTA.
>
> And also it is met by MMLV(erw)M.     To support that claim I'll just talk
> about the  Margins Sort version with 3 candidates.
>
> Plumping ballots for any X always contribute to X's   score and switching
> plumping ballots to X might get rid of one of X's pairwise defeats.
>
> If X has no pairwise defeats then that will always be still the case after
> switching some plumping ballots to X and so X will still win. X can't
> be a winner with all pairwise defeats so we are only concerned about the
> case when X has just one (and so will the other 2 candidates).
>
> Say we designate the candidate with the highest score 1, the
> second-highest 2 and and the lowest 3.   The algorithm in this 3-candidate
> cycle
> situation  elects 1 unless 2 both pairwise beats 1 and has a score that is
> closer to 1's than to 3's.
>
> If winning candidate X is in position 2 then the effect of plumping
> ballots being switched from 1 to 2  will be to just make 2 still closer to
> 1,
> and the effect of plumping ballots being switched from 3 to 2 will have
> the same effect (and make 3 further away).
>
> If winning candidate X is  1  and pairwise beats 2 and loses to 3, then
> the only hope of making 1 lose is to switch some plumping ballots from
> 2 to 1 sufficient for 2 and 3 to change places but that won't work because
> then 2 and 3 will be adjacent candidates that are out of pairwise
> order and will be much closer together score-wise than the other such pair
> and they'll be switched back to give the final order 1>2>3.
>
> And if X is 1 and losing to 2  then it means that 1's distance (scorewise)
> from 2 is such that 2 and 3 are switched in the order, and switching
> any plumping ballots to 1 will only increase that distance.
>
> I hope that (almost confused) waffle is not too confusing or opaque.
>
> Chris Benham
>
>
>
>
>
>  Mono-switch-plump:
>
> *The probability of candidate X winning must not be reduced if one or more
> ballots that
> plump for any not-X  are replaced by an equal number of ballots that plump
> for X.*
>
> Mono-raise is the traditional monotonicity criterion, but I don't see why
> anyone would
> see failure of  Mono-switch-plump as less embarrassing than failing
> Mono-raise.
>
>
> 25 A>B
> 26 B>C
> 23 C>A
> 22 C
> 04 A
>
> B>C  51-45       C>A 71-29       A>B 52-26
>
> Top Preferences:  C45 > A29 > B26
>
> When there are three candidates the MinMax , Beatpath (aka Schulze),
> Ranked Pairs and River algorithms
> are all equivalent. When they use Winning Votes as the measure of defeat
> strength they all elect C.
>
> IRV  (aka the Alternative Vote) and  Benham (and Woodall) also elect C.
> But if we replace the 4A ballots
> with 4C ballots the winner with all these methods changes from C to B.
>
> 25 A>B
> 26 B>C
> 23 C>A
> 26 C
>
> B>C  51-49       C>A 71-29       A>B 48-26
>
> Top Preferences:  C45 > B26 > A25
>
> Total Approval Chain Climbing  also fails.
>
> 25 A>B
> 06 A>C
> 32 B>C
> 27 C>A
> 08 C
> 02 B
>
> C>A>B>C,   Approvals C73 > B59 > A58
>
> TACC  elects C, but if the 2B  ballots are changed to 2C, then the winner
> changes to A.
>
> 25 A>B
> 06 A>C
> 32 B>C
> 27 C>A
> 10 C
>
> C>A>B>C,     Approvals C75 > A58 > B57
>
>
>
>
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info
>
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7859 / Virus Database: 4664/13260 - Release Date: 10/23/16
>
>
>
> ----
> 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/20161026/5bb118d9/attachment-0001.htm>