[EM] Mono-switch-Plump criterion compliance claims corrected
C.Benham
cbenham at adam.com.au
Tue Oct 25 21:08:56 PDT 2016
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 <http://www.avg.com>
> Version: 2016.0.7859 / Virus Database: 4664/13260 - Release Date: 10/23/16
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20161026/70945ac3/attachment.htm>
More information about the Election-Methods
mailing list