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