[EM] FBC, center squeeze, and CD

[Michael Ossipoff]

>
>
> MDDTR:
>
> Voters can rank as many or as few candidates as they want to.
>
>
> I surprised you aren't proposing that it use 3-slot rating ballots.
>
> The method obviously has a horrible strong random-fill incentive.
>

Yes, but as voting problems go, that doesn't seem like one of the worst.

You'd want to top-vote your top-set, and you'd want to bottom-vote your
bottom-set. But there might be an inbetween set of voters, who are a lot
better than your bottom-set, but you don't really like maybe letting their
defection-prone voters take the win from your strong top-set. They give you
a dilemma.

In MDDTR, you can, with compete safety, rank those inbetween candidatates
in order of preference, below top and above bottom. Doing so can't possibly
hurt your strong top-set.

...because of MDDTR's LNHa compliance.

Michael Ossipoff


>
> Chris Benham
>
>
>
> I should re-state the definition of MDDTR, because we haven't discussed it
> for a while.
>
> Ii don't know who introuced MDDTR. Who introduced it?
>
> MDDTR stands for Majority Defeat Disqualification, Top Ratings.
>
> MDDTR:
>
> Voters can rank as many or as few candidates as they want to.
>
> Equal rankings allowed.
>
> 1. Disqualify any candidate who has a majority pairwise defeat, unless
> everyone has one.
>
> 2. The winner is the un-disqualified candidate top-ranked by the most
> voters.
>
> [end of definition]
>
> MDDTR meets FBC & CD, an has wv-like stratgy.
>
> The cost for that is that MDDTR fails Mono-Add-Plump. I've discussed what
> that is no worse than IRV's failure of Mono-Raise. If IRV can be popular in
> spite of Mono-Raise failure, and its favorite-burial need, then MDDTR's
> Mono-Add-Plump failure shouldn't have its importance & badness exaggerated.
>
> IRV is popular here. Then there's no reason why MDDTR couldn't or
> shouldn't be at least as popular.
>
> Michael Ossipoff
>
>
>
> On Mon, Nov 7, 2016 at 4:32 PM, Michael Ossipoff <email9648742 at gmail.com>
> wrote:
>
>>
>> Chris--
>>
>> You suggested that Mono-Add-Plump failure is worse than Mono-Raise
>> failure because people care more about their favorites, and because
>> Mono-Raise failure is simpler.
>>
>> 1. Caring about favorites:
>>
>> a) So you're saying that Mono-Raise failure can't happen when someone
>> sincerely moves their favorite to top?:
>>
>> IRV:
>>
>> 31: A
>> 2: B>A (sincere is A)
>> 29: B>C
>> 30: C>A
>>
>> 1st round totals:
>>
>> A = 31
>> B = 29 + 2 = 31
>> C = 30
>>
>> C is eliminated & transferss to A
>>
>> Now A has a 61 majority and wins.
>>
>> But then the 2 B>A voters decide to sincerely raise A to top:
>>
>> 33: A
>> 29: B
>> 30: C
>>
>> B gets eliminated, and transfers to C.
>>
>> Now C has a 59 majority and wins.
>>
>> b) You care about favorite? What about when you need to rank Comprmise
>> over favorite to keep worst from winning? We're all familiar with that. In
>> Burlington, the Republicans didn't do that, and their failure to
>> favorite-bury elected their last choice.
>>
>> Yes, this isn't a monotonicity failure, but you used caring about
>> Favorite as an advantage of IRV's Mono-Raise failure over MDDTR's
>> Mono-Add-Plump failure. But obviously IRV has a bigger problem for
>> Favorite. ...the reason why IRV was repealed in Burlington.
>>
>> So please, let's not use caring about Favorite as a reason to prefer IRV
>> with its Mono-Raise failure
>> & its favorite-burial need, to MDDTR's Mono-Add Plump failure.
>>
>> 2. Simplicity:
>>
>> What could be simpler than your need, in IRV, to bury your favorite to
>> help Compromise beat Worst:
>>
>> Sincere:
>>
>> 40: C
>> 25: B>C
>> 35: A>B
>>
>> A voters vote sincerely, and B, the CWv, gets eliminated & transfers to
>> C. C wins because the A voters didn't favorite-bury.
>>
>> Strategic:
>>
>> 40: C
>> 25: B>C
>> 35: B>A (sincere is A>B)
>>
>> Now B wins.
>>
>> That's as simple as it gets. Let's not say that MDDTR's look-bad
>> criterion-failurle is simpler than IRV's serious favorite-burial need.
>>
>> Yes, I'm talking about a problem that isn't a monotonicity problem. But
>> its at least as simple as MDDTR's Mono-Add-Plump problem, and is worse
>> because it's a practical strategy problem that makes people need to
>> favorite-bury.
>>
>> Michael Ossipoff
>>
>>
>> By sincerely raising A to top, you made A lose.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Nov 7, 2016 at 2:48 AM, Michael Ossipoff <email9648742 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Sun, Nov 6, 2016 at 11:24 PM, C.Benham <cbenham at adam.com.au> wrote:
>>>
>>>> On 11/7/2016 6:07 AM, Michael Ossipoff wrote:
>>>>
>>>> ...someone could say. "You didn't just favor X. You added a ballot,
>>>> thereby spoiling a majority. It has nothing to do with the fact that you
>>>> voted for X. You could have plumped for any of various candidates, and the
>>>> effect would have been exacsly the same."
>>>>
>>>>
>>>> "Someone" could *say* that, but it wouldn't make any sense.
>>>>
>>>
>>> But how so?
>>>
>>>
>>>>
>>>> But you can't say anything like that to to explain why X lost when I
>>>> raised hir in my ranking. In that instance, making the ballot-set more
>>>> favorable to X is the _only_ thing that I'm doing.
>>>>
>>>>
>>>> Increasing the turnout is generally regarded as a good thing.  If the
>>>> method used was one of the mono-raise failing methods I like (such as IRV
>>>> and Benham), I would say:
>>>>
>>>> "Unfortunately it isn't possible for voting methods to have every
>>>> desirable property (because some of those properties are mutually
>>>> incompatible), and this method economises
>>>> by not meeting mono-raise.
>>>>
>>>
>>> Exactly. The more properties, important desirable ones, a method
>>> provides, the more of a cost there is, in terms of "embarrassment
>>> criteria", "could-look-bad".
>>>
>>> So it's a matter of what you're getting in terms of the
>>> "could-look-bad", and whether that could-look-bad could be bad in a
>>> practical way. As you suggested, MMPO's "Hitler-with-2-votes" would be bad
>>> news, and, as you suggested, is more than a "look-bad".
>>>
>>> But the Mono-Raise failure of Benham, Woodall & IRV is only a
>>> could-look-bad. It never bothered me, and never stopped me from saying good
>>> thins about those methods.
>>>
>>> Likewise the lesser look-bad of MDDTR, when it fails Mono-Add-Plump.
>>>
>>> MDDTR meets FBC & CD, and it has wv-like strategy.
>>>
>>> ...the same advantages that MMPO has.
>>>
>>> ...at the cost of Mono-Add-Plump.
>>>
>>> You like IRV, Benham & Woodall. Lots of people here love IRV. I don't
>>> reject those methods, though they aren't my main proposals, because of FBC,
>>> and the fact that there's nothing the CWs's voters can do to protects hir
>>> from losing, and the fact that Benham & Woodall are pairwise-count methods
>>> very vulnerable to pairwise-count offensive strategy, and innocent,
>>> nonstrategic truncation.
>>>
>>> If you aren't majority-favored, the elimination of the CWs is
>>> disadvantages for you. But, in Bucklin, sometimes it might not be known who
>>> the CWs is, and s/he might not defenseiveliy plump, and so s/he (& you too)
>>> lose anyway, even though it isn't IRV. I don't know that the Bucklin
>>> failure that I just described will be rarer than the IRV failure that I
>>> just described. And IRV brings some big advantages for people who are
>>> majority-favored...MMC, CD, LNHa, LNHe.
>>>
>>> If your candidate is big enough to eliminate the CW, then s/he's big
>>> enough that s/he's fairly well-known, and that CW's voters would know
>>> something about hir, and would be unlikely to reject hir & transfer the
>>> other way when s/he's close enough to what you want that you'd prefer to
>>> elect hir.
>>>
>>> So I don't reject IRV--I just don't emphasize it as a proposal.
>>>
>>> Anyway, as I said, lots of people here love IRV, and its Mono-Raise
>>> failure doesn't seem to hurt its popularity. You like IRV, and its
>>> Mono-Raise failure doesn't put you off from it. I agree with you on that.
>>>
>>> And, for the same reason, we needn't & shouldn't be put off by MDDTR's
>>> Mono-Add-Plump failure.
>>>
>>>
>>>
>>>>
>>>> But generally speaking people care most about their favourites
>>>>
>>>
>>> True.
>>>
>>>
>>>> , and IRV meets not only mono-add-plump but also mono-add-top. It's
>>>> true that after the election
>>>> some of losing candidate X's supporters could complain "If we hadn't
>>>> top-ranked X, then X would have won" but that is unlikely to be noticed and
>>>> of course isn't
>>>> true of all (or anything like all) of X's supporters.  So the X
>>>> supporters as a whole could complain "If we had been well informed and
>>>> coordinated we could have
>>>> used a mixed strategy (with not all of us voting the same way) and
>>>> elected X."
>>>>
>>>> But if voters accept the method as fair and legitimate then that
>>>> "complaint" won't be taken seriously or get much sympathy.
>>>>
>>>
>>> ...as with MDDTR.
>>>
>>>
>>>>
>>>> Just as no quasi-intelligent device should be so "stupid" as to be
>>>> confused by the very simple and spectacular MMPO failure example, neither
>>>> should it be
>>>> confused by the very very simple mono-add-plump scenario.
>>>>
>>>
>>> ...or the fact that in IRV you can make someone lose by ranking them
>>> higher?
>>>
>>>
>>>>
>>>> What (arguably) desirable properties (or criterion compliances)  are
>>>> incompatible with meeting Mono-add-Plump?
>>>>
>>>
>>> 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.
>>> That's a very small price, arguably less than IRV's Mono-Raise failure
>>> (though I note that you mentioned that Mono-Add-Plump is about a favorite).
>>>
>>> Michael Ossipoff
>>>
>>>>
>>>> Chris Benham
>>>>
>>>>
>>>> Ok, thanks, Chris, for settling that matter. I guess we have to
>>>> reluctantly give up Conditional Bucklin.
>>>>
>>>> But it would have been strategically great!
>>>>
>>>> Now, here's a question on a related topic:
>>>>
>>>> Say I arrive at the polling-place late. Before I arrive X is winning. I
>>>> show up & plump for X, and that causes X to lose.
>>>>
>>>>
>>>> ...is that worse than if I raise X in my ranking, and that causes X to
>>>> lose?
>>>>
>>>> If so, why?
>>>>
>>>> It seems to me that the latter is worse than the former.
>>>>
>>>> I if show up late and plump for X, I'm doing two things: I'm adding a
>>>> ballot, and I'm voting that ballot in a way that clearly should favor X.
>>>>
>>>> If i angrily complain, "Hey, how come, when I arrived and plumped for
>>>> X, that made X lose??!"
>>>>
>>>> ...someone could say. "You didn't just favor X. You added a ballot,
>>>> thereby spoiling a majority. It has nothing to do with the fact that you
>>>> voted for X. You could have plumped for any of various candidates, and the
>>>> effect would have been exacsly the same."
>>>>
>>>> But you can't say anything like that to to explain why X lost when I
>>>> raised hir in my ranking. In that instance, making the ballot-set more
>>>> favorable to X is the _only_ thing that I'm doing.
>>>>
>>>> So plainly violating Mono-Raise is worse than violating Mono-Add-Plump.
>>>>
>>>> Michael Ossipoff
>>>>
>>>>
>>>>
>>>> On Sun, Nov 6, 2016 at 10:27 AM, C.Benham <cbenham at adam.com.au> wrote:
>>>>
>>>>> The example I just posted of  "IBIFA with an anti-defection device"
>>>>> failing FBC I'm afraid also works for both Mike's suggested
>>>>> "Conditional Bucklin" and Forest's suggested "TopMiddleBottom".
>>>>>
>>>>> 20: F=C >>B
>>>>> 07: F > C=B   (or, for the sake of Forest's method suggestion, F >>
>>>>> C=B)
>>>>> 25: B
>>>>> 48: W
>>>>>
>>>>> All three of these methods elect W, but if the 20 F=C >> B voters
>>>>> change their rating of F from Top to Middle or Bottom
>>>>> then the winner changes to B.
>>>>>
>>>>> Chris Benham
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2016.0.7859 / Virus Database: 4664/13366 - Release Date: 11/07/16
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20161108/1607c4cd/attachment-0001.htm>