<div dir="ltr"><br><div class="gmail_extra">Chris--<br><br>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.<br><br></div><div class="gmail_extra">1. Caring about favorites:<br><br></div><div class="gmail_extra">a) So you're saying that Mono-Raise failure can't happen when someone sincerely moves their favorite to top?:<br><br></div><div class="gmail_extra">IRV:<br><br></div><div class="gmail_extra">31: A<br></div><div class="gmail_extra">2: B>A (sincere is A)<br></div><div class="gmail_extra">29: B>C<br></div><div class="gmail_extra">30: C>A<br><br></div><div class="gmail_extra">1st round totals:<br><br></div><div class="gmail_extra">A = 31<br></div><div class="gmail_extra">B = 29 + 2 = 31<br></div><div class="gmail_extra">C = 30<br><br></div><div class="gmail_extra">C is eliminated & transferss to A<br><br></div><div class="gmail_extra">Now A has a 61 majority and wins.<br><br></div><div class="gmail_extra">But then the 2 B>A voters decide to sincerely raise A to top:<br><br></div><div class="gmail_extra">33: A<br></div><div class="gmail_extra">29: B<br></div><div class="gmail_extra">30: C<br><br></div><div class="gmail_extra">B gets eliminated, and transfers to C.<br><br></div><div class="gmail_extra">Now C has a 59 majority and wins.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">So please, let's not use caring about Favorite as a reason to prefer IRV with its Mono-Raise failure <br>& its favorite-burial need, to MDDTR's Mono-Add Plump failure.<br><br></div><div class="gmail_extra">2. Simplicity:<br><br></div><div class="gmail_extra">What could be simpler than your need, in IRV, to bury your favorite to help Compromise beat Worst:<br><br></div><div class="gmail_extra">Sincere:<br><br></div><div class="gmail_extra">40: C<br></div><div class="gmail_extra">25: B>C<br></div><div class="gmail_extra">35: A>B<br><br></div><div class="gmail_extra">A voters vote sincerely, and B, the CWv, gets eliminated & transfers to C. C wins because the A voters didn't favorite-bury.<br><br></div><div class="gmail_extra">Strategic:<br><br></div><div class="gmail_extra">40: C<br></div><div class="gmail_extra">25: B>C<br></div><div class="gmail_extra">35: B>A (sincere is A>B)<br><br></div><div class="gmail_extra">Now B wins.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">Michael Ossipoff<br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">By sincerely raising A to top, you made A lose.<br><br></div><div class="gmail_extra"><br><br></div><div class="gmail_extra"><br><br><br><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 7, 2016 at 2:48 AM, Michael Ossipoff <span dir="ltr"><<a href="mailto:email9648742@gmail.com" target="_blank">email9648742@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sun, Nov 6, 2016 at 11:24 PM, C.Benham <span dir="ltr"><<a href="mailto:cbenham@adam.com.au" target="_blank">cbenham@adam.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix"><span>On 11/7/2016 6:07 AM, Michael Ossipoff
wrote:<br>
<blockquote type="cite">...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."<br>
</blockquote>
<br></span>
"Someone" could <i>say</i> that, but it wouldn't make any sense.<br></div></div></blockquote><div><br></div></span><div>But how so?<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix">
<br>
<blockquote type="cite">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.</blockquote>
<br>
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:<br>
<br>
"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<br>
by not meeting mono-raise. </div></div></blockquote><div><br></div></span><div>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".<br><br></div><div>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".<br><br></div><div>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.<br><br></div><div>Likewise the lesser look-bad of MDDTR, when it fails Mono-Add-Plump.<br><br></div><div>MDDTR meets FBC & CD, and it has wv-like strategy.<br><br></div><div>...the same advantages that MMPO has.<br><br></div><div>...at the cost of Mono-Add-Plump.<br><br></div><div>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.<br><br></div><div>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. <br><br></div><div>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.<br></div><br><div>So I don't reject IRV--I just don't emphasize it as a proposal.<br><br></div><div>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.<br><br></div><div>And, for the same reason, we needn't & shouldn't be put off by MDDTR's Mono-Add-Plump failure.<br><br></div><span class=""><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix"><br>
But generally speaking people care most about their favourites</div></div></blockquote><div><br></div></span><div>True.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix">,
and IRV meets not only mono-add-plump but also mono-add-top. It's
true that after the election<br>
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 <br>
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 <br>
used a mixed strategy (with not all of us voting the same way) and
elected X." <br>
<br>
But if voters accept the method as fair and legitimate then that
"complaint" won't be taken seriously or get much sympathy.<br></div></div></blockquote><div><br></div></span><div>...as with MDDTR.<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix">
<br>
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<br>
confused by the very very simple mono-add-plump scenario.<br></div></div></blockquote><div><br></div></span><div>...or the fact that in IRV you can make someone lose by ranking them higher?<br> <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix">
<br>
What (arguably) desirable properties (or criterion compliances)
are incompatible with meeting Mono-add-Plump?<br></div></div></blockquote><div><br></div></span><div>FBC, CD, & wv-like strategy are evidently require failing Mono-Add-Plump, or having MMPO's Hitler-with-2-votes problem.<br><br></div><div>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).<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Michael Ossipoff <br></div></font></span><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="m_786044671103368669m_-1309907814637489385moz-cite-prefix">
<br>
Chris Benham<br>
<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div><span>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Ok, thanks, Chris, for settling that
matter. I guess we have to reluctantly give up
Conditional Bucklin. <br>
<br>
But it would have been strategically great!<br>
<br>
</div>
Now, here's a question on a related topic:<br>
<br>
</div>
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.<br>
<br>
<br>
...is that worse than if I raise X in my ranking,
and that causes X to lose? <br>
<br>
If so, why?<br>
<br>
</div>
It seems to me that the latter is worse than the
former.<br>
<br>
</div>
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.<br>
<br>
</div>
If i angrily complain, "Hey, how come, when I arrived
and plumped for X, that made X lose??!"<br>
<br>
</div>
...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."<br>
<br>
</div></span>
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.<br>
<br>
</div><span>
So plainly violating Mono-Raise is worse than violating
Mono-Add-Plump. <br>
<br>
</span></div>
Michael Ossipoff<br>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div><span>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Nov 6, 2016 at 10:27 AM,
C.Benham <span dir="ltr"><<a href="mailto:cbenham@adam.com.au" target="_blank">cbenham@adam.com.au</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div class="m_786044671103368669m_-1309907814637489385m_1670892361041670316moz-cite-prefix">The
example I just posted of "IBIFA with an anti-defection
device" failing FBC I'm afraid also works for both
Mike's suggested <br>
"Conditional Bucklin" and Forest's suggested
"TopMiddleBottom".<br>
<br>
20: F=C >>B<br>
07: F > C=B (or, for the sake of Forest's method
suggestion, F >> C=B)<br>
25: B<br>
48: W<br>
<br>
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<br>
then the winner changes to B.<br>
<br>
Chris Benham
<div>
<div class="m_786044671103368669m_-1309907814637489385h5"><br>
<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</span></blockquote>
<br>
</div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>