<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>
<div>Great explanatory insight!</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div id="x_composer_signature">
<div dir="auto" style="font-size:85%; color:#575757">Sent from my MetroPCS 4G LTE Android Device</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>-------- Mensaje original --------</div>
<div>De: Kristofer Munsterhjelm <km_elmet@t-online.de> </div>
<div>Fecha: 2/8/21 2:13 p. m. (GMT-08:00) </div>
<div>A: Susan Simmons <suzerainsimmons@outlook.com>, election-methods@lists.electorama.com
</div>
<div>Asunto: Re: [EM] Agenda Based Banks </div>
<div><br>
</div>
</div>
<font size="2"><span style="font-size:11pt;">
<div class="PlainText">On 02.08.2021 21:31, Susan Simmons wrote:<br>
> It turns out that this method as it stands is not monotonic, but if you<br>
> omit the downward part, then the remaining simpler version is monotonic:<br>
> <br>
> First initialize a set named "TheBank" with the most promising agenda item. <br>
> <br>
> Then, as long as even one agenda item pairwise beats every member<br>
> ofTheBank, deposit the least promising of these into TheBank. <br>
> <br>
> Elect the final deposit.<br>
> <br>
> This simple Banks compliant method is a generalization of TACC (Total<br>
> Approval Chain Climbing).<br>
> <br>
> The only thing I don't like about it is that even when the most<br>
> promising agenda item is in the Banks set, as likely as not it will<br>
> elect a different member of that set. My tweak was designed to overcome<br>
> that "defect" while preserving Banks efficiency. But it's not worth the<br>
> loss of monotonicity. <br>
> <br>
> Furthermore, it may turn out that the supposed "defect" actually confers<br>
> burial resistance ... for example ...<br>
> <br>
> 45 A>B (sincere A>C)<br>
> 25 B>C<br>
> 30 C>A<br>
> <br>
> Ballot pairwise beat cycle: A>B>C>A<br>
> <br>
> Agenda: C<B<A<br>
> (based on implicit approval, for example)<br>
<br>
That feels like it's a general feature. Consider e.g. Benham with a<br>
preset ordering as an agenda method (remove the loser until there's a CW<br>
among the remaining candidates). Then raising W puts more candidates<br>
between W and the end of the list, which means that in the worst case,<br>
more candidates have to be eliminated before W wins.<br>
<br>
It seems like there's some kind of tension where, on the one hand, being<br>
ranked more highly should be advantageous (which it is if the pairwise<br>
preferences don't change, because it saves W from early elimination),<br>
but on the other hand, being ranked more highly with pairwise<br>
preferences changing has a higher chance of being detrimental (because<br>
more candidates have to be eliminated before W becomes a CW).<br>
<br>
-km<br>
</div>
</span></font>
</body>
</html>