<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><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_-2032166530897621082moz-cite-prefix"><span class=""><br></span><span class=""><br>
<br>
<blockquote type="cite">MDDTR:<br>
<br>
Voters can rank as many or as few candidates as they want to.<br>
</blockquote>
<br></span>
I surprised you aren't proposing that it use 3-slot rating
ballots.<br>
<br>
The method obviously has a horrible strong random-fill incentive.</div></div></blockquote><div><br></div><div>Yes, but as voting problems go, that doesn't seem like one of the worst.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>...because of MDDTR's LNHa compliance. <br><br></div><div>Michael Ossipoff<br><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_-2032166530897621082moz-cite-prefix">
<br>
<br>
Chris Benham<br>
<br>
<br>
<br>
</div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>I should re-state the definition of
MDDTR, because we haven't discussed it for a
while.<br>
<br>
</div>
Ii don't know who introuced MDDTR. Who
introduced it?<br>
<br>
</div>
MDDTR stands for Majority Defeat
Disqualification, Top Ratings.<br>
<br>
</div>
MDDTR:<br>
<br>
</div>
Voters can rank as many or as few candidates as they
want to.<br>
<br>
</div>
Equal rankings allowed.<br>
<br>
</div>
1. Disqualify any candidate who has a majority pairwise
defeat, unless everyone has one.<br>
<br>
</div>
2. The winner is the un-disqualified candidate top-ranked
by the most voters.<br>
<br>
</div>
[end of definition]<br>
<br>
</div>
MDDTR meets FBC & CD, an has wv-like stratgy.<br>
<br>
</div>
<div>
<div>
<div>
<div>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. <br>
<br>
</div>
<div>IRV is popular here. Then there's no reason why MDDTR
couldn't or shouldn't be at least as popular.<br>
<br>
</div>
<div>Michael Ossipoff<br>
</div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Nov 7, 2016 at 4:32 PM, 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">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>
<div class="m_-2032166530897621082h5">
<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>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_-2032166530897621082m_5597329454959110605m_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>
<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_-2032166530897621082m_5597329454959110605m_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>
<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_-2032166530897621082m_5597329454959110605m_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>
<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_-2032166530897621082m_5597329454959110605m_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>
<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_-2032166530897621082m_5597329454959110605m_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>
<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_-2032166530897621082m_5597329454959110605m_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="m_-2032166530897621082m_5597329454959110605HOEnZb"><font color="#888888"><br>
<br>
</font></span></div>
<span class="m_-2032166530897621082m_5597329454959110605HOEnZb"><font color="#888888">
<div>Michael Ossipoff <br>
</div>
</font></span><span>
<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_-2032166530897621082m_5597329454959110605m_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_-2032166530897621082m_5597329454959110605m_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_-2032166530897621082m_5597329454959110605m_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>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div></div><p color="#000000" align="left"><span class="">No virus
found in this message.<br>
Checked by AVG - <a href="http://www.avg.com" target="_blank">www.avg.com</a><br></span>
Version: 2016.0.7859 / Virus Database: 4664/13366 - Release
Date: 11/07/16</p>
</blockquote>
<p><br>
</p>
</div>
</blockquote></div><br></div></div>