[EM] Trying to have CD, protect strong top-set, and protect middle candidates too
C.Benham
cbenham at adam.com.au
Tue Nov 22 08:51:48 PST 2016
On 11/22/2016 9:25 AM, Michael Ossipoff wrote:
> With MDDTR, if your plump for X makes hir lose, it's because you added
> a ballot. It has nothing whatsoever to do with the fact that the new
> ballot plumped for X.
>
> Your ballot made X lose in spite of the fact that it was a plump for
> X, not because it was a plump for X.
>
> But in IRV, when you make X lose by raising hir from last place to 1st
> place, that raising of X was the only thing that you did, and it is
> the reason why X lost.
That "distinction" is meaningless and completely useless. The idea that
adding a ballot is "something you did" that rates a mention is ridiculous.
>> [Mike:] Anyway, if IRV is so widely used and successful, then why
>> would nonmonotonicity be a problem for MDDTR?
>
> [Chris:] Because IRV has a traditional and (for many) intuitive algorithm
>
> [Mike:] So, tradition before merit?
Mike, the (quoted) question of yours that I was answering was why
"*would* non-monotonicity be a problem for MDDTR?", not why it /should/.
> Chris said:
>
> Just the knowledge that a failure of Mono-add-Plump is theoretically
> possible could reduce people's enthusiasm for voting and make it more
> likely that those who like to vote by just plumping for their
> favourite will stay home.
>
> [endquote]
>
> .Then the fact that ranking someone 1st place instead of last place
> could make hir lose will likewise make you stay home instead of
> showing up and top-ranking your favorite in IRV.
> .
Monotonicity failures of the Participation-like "Your announced result
may be premature, I have only just voted, here is my ballot" type are
much more stark and
potentially problematic than the "I and everybody else has voted and the
result has been announced, but I wish to alter my ballot and have the
votes recounted"
type.
That is because (a) the media and sometimes the major parties are eager
for a quick result and usually the winner can be determined without
counting all the votes,
and (b) because it isn't practical (with a secret ballot) or legal to
allow voters to to change their already-cast ballots and demand a recount.
Suppose that a simple purely positional method (such as FPP or Approval)
has been used and voter P always just plumps for hir favourite. Now
suppose that the
method changes to IRV. No-one can ever demonstrate to voter P that
continuing to vote in the same way can ever cause a worse result for P's
favourite than if
P had stayed home.
That isn't the case with any method (like MDDTR) that fails
Mono-add-Plump. So MDDTR's failure of Mono-add-Plump makes for a much
stronger stay-at-home
incentive than IRV's vulnerability to Push-over strategy, with the
result that occasionally a subset of candidate X's supporters could have
got a better result for
X (than if they'd top-ranked X) by top-ranking some other candidate.
> Anyway, we now know that, with the pt/2 provision, MDDA & MDDTR
> needn't give up Mono-Add-Plump. ...and evidently MMPO needn't have
> the Hitler-with-2-votes problem.
>
Regarding MDDA, symmetrically completing the ballots only at the bottom
and having a moveable approval cutoff fixes its failures of Mono-add-Plump
and Plurality and Irrelevant Ballots Independence and in my opinion
makes it a good/acceptable method.
Chris Benham
On 11/22/2016 9:25 AM, Michael Ossipoff wrote:
>
>
> On Sat, Nov 19, 2016 at 12:18 AM, C.Benham <cbenham at adam.com.au
> <mailto:cbenham at adam.com.au>> wrote:
>
> On 11/19/2016 3:14 AM, Michael Ossipoff wrote:
>> If the more embarrassing Mono-Raise failure doesn't give IRV any
>> acceptance or enactment problem, then why should the less
>> embarrassing Mono-Add-Plump failure of MDDTR give MDDTR an
>> acceptance or enactment problem?
>
> Because what you consider more or less "embarrassing" I am sure
> isn't in accord with what most people would find unacceptably
> ridiculous.
>
>
> You're right. What could be considered ridiculous about making a
> candidate lose by raising hir from last choice to 1st choice in your
> ranking?
>
> :^)
>
>
>
>
>> With MDDTR, if your plump for X makes X lose, it's because you
>> added a ballot. It has nothing whatsoever to do with the fact
>> that you voted favorably to X.
>
> That's right. "You" should have found some way to vote for X
> without adding a ballot. Unfortunately removing someone else's
> ballot when you are in the
> polling station is usually impossible or legally risky.
>
>
> Then let me reword it:
>
> With MDDTR, if your plump for X makes hir lose, it's because you added
> a ballot. It has nothing whatsoever to do with the fact that the new
> ballot plumped for X.
>
> Your ballot made X lose in spite of the fact that it was a plump for
> X, not because it was a plump for X.
>
> But in IRV, when you make X lose by raising hir from last place to 1st
> place, that raising of X was the only thing that you did, and it is
> the reason why X lost.
>
>
>> Anyway, if IRV is so widely used and successful, then why would
>> nonmonotonicity be a problem for MDDTR?
>
> Because IRV has a traditional and (for many) intuitive algorithm
>
>
> So, tradition before merit?
>
> , and a solid "maximal" set of criterion compliances and MDDTR
> doesn't.
>
>
> No doubt everyone has own definition of "solid maximal".
>
> MDDTR avoids chicken dilemma and meets FBC.
>
> IRV avoids chicken dilemma but fails FBC.
>
> IRV was thrown out in Burlington because the CWs's voters have no way
> to protect hir from defeat if hir faction is smallest, and neither
> does anyone else, short of favorite-burial.
>
> MDDTR doesn't have that problem. Though MDDTR's protection of a CWs
> isn't as good as that of Simmons (unless, with Simmons, that CWs is
> being denied approval due to a chicken-dilemma situation), MDDTR still
> offers some burial deterrence (helped by voters, including the CWs's
> voters, refusing to rank past the CWs), and full truncation-proofness.
>
> IRV is pretty much unique, in the degree to which no one can do
> anything to protect a small-faction CWs.
>
> I don't oppose IRV, though I don't advocate it either (unless the only
> alternative is no change from Plurality).
>
> As I said in another thread, IRV's long track-record in elections for
> national office, is one of 2-party domination.
>
>
> Earlier you attempted to ridicule my observation that MDDTR fails
> Irrelevant Ballots Independence by suggesting that might
> indirectly motivate a higher
> turnout.
>
>
> There's nothing wrong with working to increase turnout.
>
> Well, just as some might have an interest in promoting that (for
> voters who'll ignore the competitive/viable candidates) so as to
> wash away
> an otherwise likely majority-defeat disqualification so would
> opposed forces have an interest in doing the opposite.
>
>
> Sure, some might have incentive to suppress turnout. That that's true
> anyway, with any method. Anyway, measures to reduce turnout would be
> difficult to justify in Congress, and, in some instances, under
> existing law, would be illegal. I don't think that turnout-suppression
> with MDDTR would be a problem.
>
> In any case, the Mono-Add-Plump failure of MDDA & MDDTR is now moot,
> because it's avoided by the pt/2 provision.
>
>
> Chris said:
>
> Just the knowledge that a failure of Mono-add-Plump is theoretically
> possible could reduce people's enthusiasm for voting and make it more
> likely that those who like to vote by just plumping for their
> favourite will stay home.
>
> [endquote]
>
> .Then the fact that ranking someone 1st place instead of last place
> could make hir lose will likewise make you stay home instead of
> showing up and top-ranking your favorite in IRV.
> .
> Chris said:
>
> Whereas IRV doesn't just meet mono-add-plump. It also meet Mono-add-Top
>
> [endquote]
>
> ...and fails Mono-Raise, and fails FBC in a particularly flagrant way
> that won't be unusual..
>
>> C: Failing mono-add-plump is as stupid as a quasi-"intelligent"
>> device can be, in a pure and starkly obvious way, and with the lamest
>> possible excuse.
>>
>> The algorithm/device decides that X should win, and then receives
>> some more ballots that contain nothing whatsoever but the pure and
>> simple message:
>> "You are right! X should win" and responds with the bizarre
>> malfunction "I've changed my mind, Y should win" and offers the
>> nonsensical excuse "Hey those
>> extra ballots didn't just say that X should win. They also increased
>> the total number of ballots!".
>>
>>
>>> C: What (arguably) desirable properties (or criterion compliances)
>>> are incompatible with meeting Mono-add-Plump?
>>>
>>> Mike: FBC, CD, & wv-like strategy are evidently require failing
>>> Mono-Add-Plump, or having MMPO's Hitler-with-2-votes problem.
>>>
>>> With MDDTR, the price of FBC, CD & wv-like strategy is Mono-Add-Plump.
>>
>> C: There are methods that meet FBC and CD and mono-add-plump. So
>> your proposition boils down to saying that it's worth giving up
>> compliance with
>> mono-add-plump just to gain "wv-like strategy"
>>
>> .
> Sure, I'm more interested in making voting easier, and making
> sincerity safer, than in embarrassment criteria. (...and IRV has an at
> least equally ridiculous nonmonotonicity).
>
> I now realize that MDDTR doesn't have wv strategy, though it does have
> full truncation-proofness.
>
> Simmons, MMPO(pt/2), IC,MMPO, and probably other methods meet FBC &
> CD, and let voters protect a CWs to varying degrees under different
> conditions...something that you have to give up when you choose IRV,
> in which a CWs automatically loses if its faction is smallest.
>
> I'm not saying that the overall IRV package couldn't be ok, if people
> understand and accept IRV's problem and won't let it make them
> favorite-bury.
>
> Anyway, we now know that, with the pt/2 provision, MDDA & MDDTR
> needn't give up Mono-Add-Plump. ...and evidently MMPO needn't have
> the Hitler-with-2-votes problem.
>
> Michael Ossipoff
>
> Chris Benham
>
>
>
> On 11/19/2016 3:14 AM, Michael Ossipoff wrote:
>
>> I don't mean that IRV isn't ok. IRV's Mono-Raise failure doesn't
>> bother me.
>> Neither does MDDTR's Mono-Add-Plump failure.
>>
>> Voting's purpose is probabilistic anyway. You vote to improve the
>> probability of a better outcome. The possible nonmonotonicity of IRV
>> & MDDTR doesn't invalidate that.
>>
>> My point, in asking about when you make someone lose by raising
>> hir from last place to 1st place, was just that IRV is popular
>> and widely used. It's been used in Australia for a long time, and
>> it's used in a fair number of cities in this country. ...and now
>> has been adopted by the state of Maine.
>>
>> ...in spite of its Mono-Raise failure.
>>
>> If the more embarrassing Mono-Raise failure doesn't give IRV any
>> acceptance or enactment problem, then why should the less
>> embarrassing Mono-Add-Plump failure of MDDTR give MDDTR an
>> acceptance or enactment problem?
>>
>> There of course have been objections to IRV, some valid, some
>> not. But I haven't heard any of the IRV critics in the various
>> cities complain about its nonmonotonicity. They object to
>> implementation complexity. They invalidly claim voting
>> complexity. They invalidly complain because supposedly voting is
>> supposed to be by Plurality. They repealed IRV in Burlington
>> because of the elimination of a CWv. But none of the complaints
>> that I've heard, in cities using it or considering IRV, have been
>> about its nonmonotonicity.
>>
>> Why I say that Mono-Raise failure is more embarrassing:
>>
>> With MDDTR, if your plump for X makes X lose, it's because you
>> added a ballot. It has nothing whatsoever to do with the fact
>> that you voted favorably to X.
>>
>> With IRV, if raising X from bottom to top makes X lose, then X
>> lost for no other reason than because you helped hir more.
>>
>> There are 2 kinds of nonmonotonicity:
>>
>> Did you make X lose _in spite of_ voting favorably for hir?
>>
>> or
>>
>> Did you make X lose _because_ you voted hir more favorably?
>>
>> Of those 2 kinds of nonmonotonicity the 2nd one is more of an
>> embarrassment to the method. There, the method is more directly
>> acting oppositely to your action.
>>
>> Maybe it could be said that the 2nd kind of nonmonotonicity is
>> twice as embarrassing to the voting-system.
>>
>> Anyway, if IRV is so widely used and successful, then why would
>> nonmonotonicity be a problem for MDDTR?
>>
>> I now feel that IRV's (mitigated) problem isn't an unusually high
>> price for CD, isn't more than the "going rate" for CD. IRV & its
>> derivatives are at the top of my ranking of method-merit for
>> electorates who want &/or need ranking.
>>
>> Michael Ossipoff
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Nov 18, 2016 at 1:23 AM, Michael Ossipoff
>> <email9648742 at gmail.com <mailto:email9648742 at gmail.com>> wrote:
>>
>> Forest--
>>
>> You wrote:
>>
>>
>> But MAI still fails FBC.
>>
>>
>> Failing both FBC & CD isn't good.
>>
>>
>> So to me the best proposal is ICA with default approval
>> cutoff at truncation to help punish burial and truncation
>> with an option to raise the cutoff to withstand a CD attack.
>>
>>
>> But buriers or truncators could raise that approval cutoff
>> too. Someone could bury X under Z without having to approve
>> Z. That loses the deterrence that would exist if that burier
>> had to approve Z in order to rank hir over someone, as would
>> be so if ranking is counted as approval.
>>
>> So CD still comes at the cost of a lot less protection
>> against burial, or, in ICT's case, trunction too.
>>
>> But that just means that it isn't _better_ than MDDTR in that
>> regard. It doesn't mean that it's worse.
>>
>> And it doesn't have Mono-Add-Plump failure.
>>
>> So, the method has CD as MDDTR does, and trades
>> truncation-proofness for Mono-Add-Plump.
>>
>> I value strategy protections more than embarrassment
>> criteria. (But I realize that proposal-opponents can use
>> embarrassment criteria criticisms, and that proponents aren't
>> likely to be able to afford as much media time, to answer the
>> criticisms.)
>>
>> [Replying farther down] :
>>
>>
>>
>> Here's my version (slightly different from the original):
>>
>> Candidate X strongly beats candidate Y iff
>>
>> the number of ballots on which X is ranked over Y is
>> greater than
>>
>> the number of ballots on which Y is _/*ranked*/_ equal to
>> or greater than Y.
>>
>> [Note Y is not ranked equal to X if Y is not ranked.]
>>
>> If not all of the candidates are strongly beaten,
>> disqualify all of the ones who are.
>>
>> Elect the most approved qualified candidate.
>>
>> I think that this method has all of the good properties
>> of MDDA with mono-add-plump to boot.
>>
>>
>> I've only had a preliminary look at it, but it seems to me,
>> right now, that the separate approval-cutoff that the voter
>> can raise from the default spoils protection from burial &
>> truncation.
>>
>>
>> You wrote:
>>
>> We still need to explore MDDA with the half power
>> truncation rule, since it would also satisfy
>> mono-add-plump if I am not mistaken.
>>
>>
>> Yes, it seems to me that a 1/2 power-truncation would get rid
>> of the Mono-Add-Plump failure. If, by not ranking a certain 2
>> candidates, you give them each at least half of a vote
>> against eachother, that would bring Mono-Add-Plump
>> compliance, it seems to me.
>>
>> So maybe it would avoid criticism of MDDA.
>>
>> But, if used with MDDTR, it would spoil CD.
>>
>> You wrote:
>>
>>
>>
>> I agree with Chris Benham that mono-add-plump failure
>> would be fatal in a public proposal.
>>
>>
>> What if you're going to rank X last in your ranking. With all
>> the ballots, including yours, X will win. But then you move X
>> to 1st place in your ranking, and that makes X lose.
>>
>> Would that be ok?
>>
>> Michael Ossipoff
>>
>>
>> On Thu, Nov 17, 2016 at 2:12 PM, Michael Ossipoff
>> <email9648742 at gmail.com <mailto:email9648742 at gmail.com>>
>> wrote:
>>
>> I meant to ask: Did you say that MTRI doesn't pass
>> FBC? How does FBC failure happen? In return for FBC,
>> it should beat MDDTR at vulnerability to burial, and
>> not be vulnerable to truncation.
>>
>> Anyway, anything you can tell me about the properties
>> comparison between MTRI & MDDTR would be helpful.
>>
>> MIchael Ossipoff
>>
>> On Thu, Nov 17, 2016 at 5:05 PM, Michael Ossipoff
>> <email9648742 at gmail.com
>> <mailto:email9648742 at gmail.com>> wrote:
>>
>> For this method, MTRI, the procedural definition
>> is more understandable than the recursive
>> definition (though the recursive definition's
>> brevity could be useful).
>>
>> So this is what I understand MTRI's procedural
>> definition to be:
>>
>> 1. Order the candidates by their top-count score,
>> with higher scores at top.
>>
>> 2. Switch the lowest pair of adjacent candidates
>> whose lower candidate pair-beats the higher one.
>>
>> Repeat till there are no more pairs to switch.
>> The highest candidate in the order at that time wins.
>>
>> -----------------------------------------------
>>
>> As a CD rank method, this method is a competitor
>> of MDDTR. What are the property differences
>> between MTRI & MDDTR?
>>
>> In particular, how does MTRI compare with MDDTR
>> in regards to protection of a CWs against
>> truncation & burial?
>>
>> Michael Ossipoff
>>
>>
>> On Thu, Nov 17, 2016 at 2:55 PM, Forest Simmons
>> <fsimmons at pcc.edu <mailto:fsimmons at pcc.edu>> wrote:
>>
>> On Thu, Nov 17, 2016 at 10:54 AM, Michael
>> Ossipoff <email9648742 at gmail.com
>> <mailto:email9648742 at gmail.com>> wrote:
>>
>> But wouldn't Smith//Approval, with
>> approval cutoffs in the rankings, share
>> MDDTR's burial-vullnerability?
>>
>> ...with, additionally, vulnerability to
>> truncation, which MDDTR _doesn't_ have?
>>
>> And Smith//Approval trades MDDTR's FBC
>> for Smith, which I consider an
>> unfavorable trade.
>>
>>
>> Perhaps make truncation the default approval
>> cutoff, but let voters move it higher as an
>> option:
>>
>> 45 C
>> 30 A>B or A>>B
>> 25 B
>>
>> Voting A>>B would be the chicken defense
>> (where sincere is 25 B>A).
>>
>> Voting A>B would be the truncation defense
>> (where sincere is 45 C>B).
>>
>> With this option, MDDA would be an FBC
>> compliant method that is truncation and
>> burial resistant as well as quasi CD compliant.
>>
>> Is there a way to modify MDDA to make it
>> satisfy mono-add-plump?
>>
>> How about incorporating some form of power
>> truncation. When you plump X and reduce the
>> majority victory of Y over Z to a
>> sub-majority, it would revert to a majority
>> if you counted the common truncation of Y and
>> Z against each other as even half a point.
>>
>> Btw, in case you didn't see it, one of my new
>> favorite non-FBC methods is Most Approved
>> Immune(MAI): Elect the most approved immune
>> candidate.
>>
>> This means elect the most approved candidate
>> X that is unbeaten pairwise by the candidate
>> that would win (recursively) if the method
>> were applied to the same ballot set with X
>> disqualified or withdrawn.
>>
>> It is the simplest approval based rank method
>> that confers immunity from second place
>> complaints on its winners.
>>
>> It is quasi CD compliant if voters can
>> specify their approval cutoffs above the
>> truncation level when they want to.
>>
>> A top rank version of this method is fully CD
>> compliant:
>>
>> Elect the Most Top Ranked Immune candidate.
>> (MTRI)
>>
>> In other words elect the most top ranked
>> candidate X that is unbeaten pairwise by the
>> candidate that would win (recursively) if the
>> method were applied to the same ballot set
>> with X disqualified or withdrawn.
>>
>> Forest
>>
>>
>>
>>
>>
>>
>>
>
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2016.0.7859 / Virus Database: 4664/13452 - Release Date: 11/21/16
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20161123/6e63a751/attachment-0001.htm>
More information about the Election-Methods
mailing list