<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 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 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 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 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 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 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>