<div dir="ltr"><div>Forest--<br><br></div>You wrote:<br><div><div><div><div class="gmail_extra"><div class="gmail_quote"><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><div>Failing both FBC & CD isn't good.<br> <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><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><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><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><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><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><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><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="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div></div></blockquote><div><br></div><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>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="HOEnZb"><div class="h5"><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_2209416936795919876HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_2209416936795919876HOEnZb"><font color="#888888">MIchael Ossipoff<br></font></span></div><div class="m_2209416936795919876HOEnZb"><div class="m_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_2209416936795919876m_-3518268541538704350HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_2209416936795919876m_-3518268541538704350HOEnZb"><font color="#888888">Michael Ossipoff<br><br></font></span></div><div class="m_2209416936795919876m_-3518268541538704350HOEnZb"><div class="m_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_2209416936795919876m_-3518268541538704350m_7800393914769801655HOEnZb"><font color="#888888"><br><br></font></span></div><span class="m_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><br></div></div></div></div></div>