<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 11/22/2016 9:25 AM, Michael Ossipoff
wrote:<br>
<br>
<blockquote type="cite">
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
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.</blockquote>
<br>
That "distinction" is meaningless and completely useless. The
idea that adding a ballot is "something you did" that rates a
mention is ridiculous.<br>
<br>
<blockquote type="cite"><span class="">
<blockquote type="cite">[Mike:] Anyway, if IRV is so widely
used and successful, then why would nonmonotonicity be a
problem for MDDTR?</blockquote>
<br>
</span> [Chris:] Because IRV has a traditional and (for many)
intuitive algorithm
<div><br>
</div>
<div>[Mike:] So, tradition before merit?</div>
</blockquote>
<br>
Mike, the (quoted) question of yours that I was answering was why
"<b>would</b> <span class=""> non-monotonicity be a problem for
MDDTR?", not why it <i>should</i>.<br>
<br>
</span>
<blockquote type="cite">
<div class="m_-5996776559525049224moz-cite-prefix">Chris said:<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"> <br>
Just the knowledge that a failure of Mono-add-Plump is
theoretically possible could reduce people's enthusiasm for
voting and make it more<br>
likely that those who like to vote by just plumping for their
favourite will stay home. <br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">[endquote]<br>
<br>
</div>
.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.<br>
.<span class=""><br>
</span></blockquote>
<br>
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<br>
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"<br>
type.<br>
<br>
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,<br>
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.<br>
<br>
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 <br>
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<br>
P had stayed home. <br>
<br>
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<br>
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<br>
X (than if they'd top-ranked X) by top-ranking some other
candidate.<br>
<br>
<blockquote type="cite">
<div class="m_-5996776559525049224moz-cite-prefix">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.<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"><br>
</div>
</blockquote>
<br>
Regarding MDDA, symmetrically completing the ballots only at the
bottom and having a moveable approval cutoff fixes its failures of
Mono-add-Plump<br>
and Plurality and Irrelevant Ballots Independence and in my
opinion makes it a good/acceptable method.<br>
<br>
Chris Benham<br>
<br>
<br>
<span class=""></span><br>
On 11/22/2016 9:25 AM, Michael Ossipoff wrote:<br>
</div>
<blockquote
cite="mid:CAOKDY5Dn4eMf_JS4_+C99287BG8Card1StXoUTyvVWQR60ejvA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Nov 19, 2016 at 12:18 AM,
C.Benham <span dir="ltr"><<a moz-do-not-send="true"
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_-5996776559525049224moz-cite-prefix"><span
class="">On 11/19/2016 3:14 AM, Michael Ossipoff
wrote:<br>
<blockquote type="cite">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?</blockquote>
<br>
</span> Because what you consider more or less
"embarrassing" I am sure isn't in accord with what
most people would find unacceptably ridiculous.</div>
</div>
</blockquote>
<div><br>
</div>
<div>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? <br>
<br>
:^)<br>
<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_-5996776559525049224moz-cite-prefix"> <br>
<span class=""> <br>
<blockquote type="cite">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.</blockquote>
<br>
</span> 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 <br>
polling station is usually impossible or legally
risky.<span class=""><br>
</span></div>
</div>
</blockquote>
<div><br>
</div>
<div>Then let me reword it: <br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<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_-5996776559525049224moz-cite-prefix"><span
class=""> <br>
<blockquote type="cite">Anyway, if IRV is so widely
used and successful, then why would
nonmonotonicity be a problem for MDDTR?</blockquote>
<br>
</span> Because IRV has a traditional and (for many)
intuitive algorithm</div>
</div>
</blockquote>
<div><br>
</div>
<div>So, tradition before merit?<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_-5996776559525049224moz-cite-prefix">, and
a solid "maximal" set of criterion compliances and
MDDTR doesn't.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>No doubt everyone has own definition of "solid
maximal".<br>
<br>
</div>
<div>MDDTR avoids chicken dilemma and meets FBC. <br>
<br>
IRV avoids chicken dilemma but fails FBC.<br>
<br>
</div>
<div>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.<br>
<br>
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.<br>
<br>
</div>
<div>IRV is pretty much unique, in the degree to which no
one can do anything to protect a small-faction CWs.<br>
<br>
</div>
<div>I don't oppose IRV, though I don't advocate it either
(unless the only alternative is no change from Plurality).<br>
<br>
</div>
<div>As I said in another thread, IRV's long track-record in
elections for national office, is one of 2-party
domination.<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_-5996776559525049224moz-cite-prefix"> <br>
Earlier you attempted to ridicule my observation that
MDDTR fails Irrelevant Ballots Independence by
suggesting that might indirectly motivate a higher<br>
turnout. </div>
</div>
</blockquote>
<div><br>
</div>
<div>There's nothing wrong with working to increase turnout.<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_-5996776559525049224moz-cite-prefix">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<br>
an otherwise likely majority-defeat disqualification
so would opposed forces have an interest in doing the
opposite.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">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.<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">In any
case, the Mono-Add-Plump failure of MDDA & MDDTR is
now moot, because it's avoided by the pt/2 provision.<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"><br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">Chris
said:<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"> <br>
Just the knowledge that a failure of Mono-add-Plump is
theoretically possible could reduce people's enthusiasm
for voting and make it more<br>
likely that those who like to vote by just plumping for
their favourite will stay home. <br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">[endquote]<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">.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.<br>
.<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"> Chris
said:<br>
<br>
Whereas IRV doesn't just meet mono-add-plump. It also meet
Mono-add-Top<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">[endquote]<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">...and
fails Mono-Raise, and fails FBC in a particularly flagrant
way that won't be unusual..<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"> <br>
<blockquote type="cite">
<div>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.<br>
<br>
The algorithm/device decides that X should win, and
then receives some more ballots that contain nothing
whatsoever but the pure and simple message:<br>
"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<br>
extra ballots didn't just say that X should win. They
also increased the total number of ballots!".<br>
<br>
<br>
<blockquote type="cite">C: What (arguably) desirable
properties (or criterion compliances) are
incompatible with meeting Mono-add-Plump?<br>
<div><br>
</div>
<div>Mike: FBC, CD, & wv-like strategy are
evidently require failing Mono-Add-Plump, or
having MMPO's Hitler-with-2-votes problem.<br>
<br>
</div>
With MDDTR, the price of FBC, CD & wv-like
strategy is Mono-Add-Plump.</blockquote>
<br>
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 <br>
mono-add-plump just to gain "wv-like strategy"<br>
<br>
</div>
.</blockquote>
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).<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">I now
realize that MDDTR doesn't have wv strategy, though it
does have full truncation-proofness.<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">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.<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">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.<br>
<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">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.<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"><br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix">Michael
Ossipoff<br>
</div>
<div class="m_-5996776559525049224moz-cite-prefix"><br>
Chris Benham
<div>
<div class="h5"><br>
<br>
<br>
On 11/19/2016 3:14 AM, Michael Ossipoff wrote:<br>
</div>
</div>
</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>
<div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>I don't mean that
IRV isn't ok. IRV's
Mono-Raise failure
doesn't bother me.<br>
</div>
<div>Neither does
MDDTR's
Mono-Add-Plump
failure. <br>
</div>
<div><br>
</div>
Voting's purpose is
probabilistic anyway.
You vote to improve
the probability of a
better outcome. The
possible
nonmonotonicity of IRV<br>
</div>
& MDDTR doesn't
invalidate that.<br>
<br>
</div>
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.<br>
<br>
</div>
...in spite of its
Mono-Raise failure.<br>
<br>
</div>
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?<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Why I say that Mono-Raise
failure is more embarrassing:<br>
<br>
</div>
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.<br>
<br>
</div>
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.<br>
<br>
</div>
There are 2 kinds of
nonmonotonicity:<br>
<br>
</div>
Did you make X lose _in spite of_
voting favorably for hir?<br>
<br>
</div>
or<br>
<br>
</div>
Did you make X lose _because_ you voted
hir more favorably?<br>
<br>
</div>
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.<br>
<br>
</div>
Maybe it could be said that the 2nd kind of
nonmonotonicity is twice as embarrassing to
the voting-system.<br>
<br>
</div>
<div>Anyway, if IRV is so widely used and
successful, then why would nonmonotonicity be
a problem for MDDTR?<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>Michael Ossipoff<br>
<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
<div>
<div>
<div>
<div><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Nov 18, 2016 at
1:23 AM, Michael Ossipoff <span dir="ltr"><<a
moz-do-not-send="true"
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">
<div>Forest--<br>
<br>
</div>
You wrote:<br>
<div>
<div>
<div>
<div class="gmail_extra">
<div class="gmail_quote"><span>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
But MAI still
fails FBC.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Failing both FBC & CD
isn't good.<br>
<br>
</div>
<span>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
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.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>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.<br>
<br>
</div>
<div>So CD still comes at the
cost of a lot less protection
against burial, or, in ICT's
case, trunction too.<br>
<br>
</div>
<div>But that just means that it
isn't _better_ than MDDTR in
that regard. It doesn't mean
that it's worse.<br>
<br>
</div>
<div>And it doesn't have
Mono-Add-Plump failure.<br>
<br>
</div>
<div>So, the method has CD as
MDDTR does, and trades
truncation-proofness for
Mono-Add-Plump.<br>
<br>
</div>
<div>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.)<br>
<br>
</div>
<div>[Replying farther down] :<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 dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
Here's my
version
(slightly
different from
the original):<br>
<br>
</div>
Candidate X
strongly beats
candidate Y iff<br>
<br>
</div>
the number of
ballots on which X
is ranked over Y
is greater than<br>
<br>
</div>
the number of
ballots on which Y
is <u><i><b>ranked</b></i></u>
equal to or greater
than Y.<br>
<br>
</div>
[Note Y is not ranked
equal to X if Y is not
ranked.]<br>
<br>
</div>
If not all of the
candidates are strongly
beaten, disqualify all
of the ones who are.<br>
<br>
Elect the most approved
qualified candidate.<br>
<br>
</div>
<div>I think that this
method has all of the
good properties of MDDA
with mono-add-plump to
boot.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>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.<br>
<br>
</div>
<span>
<div><br>
</div>
<div>You wrote: <br>
</div>
<div> </div>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div>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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>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.<br>
<br>
</div>
<div>So maybe it would avoid
criticism of MDDA.<br>
</div>
<div><br>
</div>
<div>But, if used with MDDTR, it
would spoil CD.<br>
<br>
</div>
<span>
<div>You wrote:<br>
<br>
</div>
<div><br>
</div>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>I agree with Chris
Benham that
mono-add-plump failure
would be fatal in a
public proposal.<br>
</div>
</div>
<div
class="m_-5996776559525049224m_-5967753060088133619HOEnZb">
<div
class="m_-5996776559525049224m_-5967753060088133619h5">
<div class="gmail_extra"><br>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>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.<br>
<br>
</div>
<div>Would that be ok?<br>
<br>
</div>
<div>
<div
class="m_-5996776559525049224h5">
<div>Michael Ossipoff<br>
<br>
</div>
<div><br>
</div>
<blockquote
class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div
class="m_-5996776559525049224m_-5967753060088133619HOEnZb">
<div
class="m_-5996776559525049224m_-5967753060088133619h5">
<div
class="gmail_extra">
<div
class="gmail_quote">On
Thu, Nov 17, 2016
at 2:12 PM,
Michael Ossipoff <span
dir="ltr"><<a
moz-do-not-send="true" 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">
<div>
<div>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.<br>
<br>
</div>
Anyway,
anything you
can tell me
about the
properties
comparison
between MTRI
& MDDTR
would be
helpful.<span
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876HOEnZb"><font
color="#888888"><br>
<br>
</font></span></div>
<span
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876HOEnZb"><font
color="#888888">MIchael Ossipoff<br>
</font></span></div>
<div
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876HOEnZb">
<div
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876h5">
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Nov 17,
2016 at 5:05
PM, Michael
Ossipoff <span
dir="ltr"><<a
moz-do-not-send="true" 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">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>For this
method, MTRI,
the procedural
definition is
more
understandable
than the
recursive
definition
(though the
recursive
definition's
brevity could
be useful).<br>
<br>
</div>
So this is
what I
understand
MTRI's
procedural
definition to
be:<br>
<br>
</div>
1. Order the
candidates by
their
top-count
score, with
higher scores
at top.<br>
<br>
</div>
2. Switch the
lowest pair of
adjacent
candidates
whose lower
candidate
pair-beats the
higher one.<br>
<br>
</div>
Repeat till
there are no
more pairs to
switch. The
highest
candidate in
the order at
that time
wins.<br>
<br>
------------------------------<wbr>-----------------<br>
<br>
</div>
As a CD rank
method, this
method is a
competitor of
MDDTR. What
are the
property
differences
between MTRI
& MDDTR?<br>
</div>
<br>
</div>
In particular,
how does MTRI
compare with
MDDTR in
regards to
protection of
a CWs against
truncation
& burial?<span
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350HOEnZb"><font
color="#888888"><br>
<br>
</font></span></div>
<span
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350HOEnZb"><font
color="#888888">Michael Ossipoff<br>
<br>
</font></span></div>
<div
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350HOEnZb">
<div
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350h5">
<div
class="gmail_extra"><br>
<div
class="gmail_quote">On
Thu, Nov 17,
2016 at 2:55
PM, Forest
Simmons <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:fsimmons@pcc.edu" target="_blank">fsimmons@pcc.edu</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"><span>On
Thu, Nov 17,
2016 at 10:54
AM, Michael
Ossipoff <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:email9648742@gmail.com"
target="_blank">email9648742@gmail.com</a>></span>
wrote:<br>
</span>
<div
class="gmail_extra">
<div
class="gmail_quote"><span>
<blockquote
style="margin:0px
0px 0px
0.8ex;border-left:1px
solid
rgb(204,204,204);padding-left:1ex"
class="gmail_quote">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>But
wouldn't
Smith//Approval,
with approval
cutoffs in the
rankings,
share MDDTR's
burial-vullnerability?<br>
<br>
</div>
...with,
additionally,
vulnerability
to truncation,
which MDDTR
_doesn't_
have?<br>
<br>
</div>
And
Smith//Approval
trades MDDTR's
FBC for Smith,
which I
consider an
unfavorable
trade.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
</span>
<div>Perhaps
make
truncation the
default
approval
cutoff, but
let voters
move it higher
as an option:<br>
<br>
</div>
<div>45 C<br>
</div>
<div>30 A>B
or A>>B<br>
</div>
<div>25 B<br>
<br>
</div>
<div>Voting
A>>B
would be the
chicken
defense (where
sincere is 25
B>A).<br>
<br>
</div>
<div>Voting
A>B would
be the
truncation
defense (where
sincere is 45
C>B).<br>
<br>
</div>
<div>With this
option, MDDA
would be an
FBC compliant
method that is
truncation and
burial
resistant as
well as quasi
CD compliant.<br>
<br>
</div>
<div>Is there
a way to
modify MDDA to
make it
satisfy
mono-add-plump?<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>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.<br>
<br>
</div>
<div>It is the
simplest
approval based
rank method
that confers
immunity from
second place
complaints on
its winners.<br>
<br>
</div>
<div>It is
quasi CD
compliant if
voters can
specify their
approval
cutoffs above
the truncation
level when
they want to.<br>
<br>
</div>
<div>A top
rank version
of this method
is fully CD
compliant:<br>
<br>
</div>
<div>Elect the
Most Top
Ranked Immune
candidate.
(MTRI)<br>
<br>
</div>
<div>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.<span
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350m_7800393914769801655HOEnZb"><font
color="#888888"><br>
<br>
</font></span></div>
<span
class="m_-5996776559525049224m_-5967753060088133619m_2209416936795919876m_-3518268541538704350m_7800393914769801655HOEnZb"><font
color="#888888">
<div>Forest<br>
</div>
</font></span></div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<p color="#000000" align="left"><br>
</p>
</blockquote>
<p><br>
</p>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<p class="" avgcert""="" color="#000000" align="left">No virus
found in this message.<br>
Checked by AVG - <a moz-do-not-send="true"
href="http://www.avg.com">www.avg.com</a><br>
Version: 2016.0.7859 / Virus Database: 4664/13452 - Release
Date: 11/21/16</p>
</blockquote>
<p><br>
</p>
</body>
</html>