<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Helvetica, Arial, sans-serif">Mostly I agree with Chris.<br>
<br>
It's hard to say how many candidates should make it through to the
final (Condorcet) round of voting. We can only guess at how
effective the proposed primary methods would be, and our knowledge
of the performance of ranked voting systems is based largely on
idealised evaluations. <br>
<br>
I posted some figures a while ago indicating that as the level of
truncation increased, some strange reversals set in just after the
half-way mark: the Borda count briefly gained in accuracy while
Condorcet methods started a headlong fall. After this point the
Borda count outperforms Condorcet methods. (The figures relate to
sincere voting; there's no suggestion that Condorcet methods
become more manipulable than the Borda count.) This suggests that
we should keep the field small enough to expect voters to rank at
least half the candidates, or motivate them to rank more than they
would naturally be inclined to, or abandon standard voting theory
in favour of methods tailored to truncated ballots. I have a
suggestion on the second head which I'll make in another thread.<br>
<br>
I think I favour a fixed maximum field size. We want to ensure
that the number of candidates is not more than will be voted on
accurately; we don't want to discard the candidate closest to the
median of the voter distribution; jointly satisfying these two
desiderata requires a fair degree of subtletly, and there are
other parts of the election system which will give better rewards
to algorithmic complexity.<br>
<br>
CJC<br>
</font><br>
<div class="moz-cite-prefix">On 30/08/2023 09:17, Chris Benham
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:46348150-fd67-6d41-7b4d-6d6c2aa154b3@yahoo.com.au">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p><br>
Kristofer,<br>
<br>
IMHO this is all far too complicated and completely
wrong-headed.<br>
<br>
For one thing, it seems to assume that major candidates have
some interest in,<br>
or in some way benefit from, displacing minor candidates off the
final ballot.<br>
<br>
In fact, with voluntary voting, they are just as likely to be
harmed by them doing that<br>
as helped. Major moderate wing candidates can benefit by minor
(sure loser) more extreme <br>
candidates on the same wing being on the ballot, because they
inspire more voters to turn out<br>
who will help that moderate wing candidate to defeat the other
major candidate/s.<br>
<br>
So with your suggested method, a candidate could lose the
election because it did too well in<br>
the primary.<br>
<br>
I only recently saw the first message in this thread, and was a
bit surprised that the N suggested<br>
was so small and elastic ("2-5").<br>
<br>
My suggested solution assumed a fixed N. I would have no
problem with 7, certainly at least 5.<br>
<br>
If we are happy to have N elastic because we don't want any very
weak candidates on the ballot,<br>
then we can do IRV-style eliminations and vote transfers until
the lowest tally of any not eliminated<br>
candidate meets some arbitrary threshold and then we stop.<br>
<br>
Or we can combine that with saying we are going to have at most
X candidates.<br>
</p>
<p>I think I prefer a quite high fixed number. Lots of candidates
can help inspire turnout and make for<br>
a wider and more interesting "battle of ideas".<br>
<br>
Chris B.<br>
</p>
<p><br>
</p>
<p><br>
<br>
<br>
<br>
</p>
<blockquote type="cite"><b>Kristofer Munsterhjelm</b> <a
href="mailto:election-methods%40lists.electorama.com?Subject=Re%3A%20%5BEM%5D%20Condorcet%20meeting&In-Reply-To=%3Ca4347551-24f9-f38b-be5b-bb3da1a4f5e3%40t-online.de%3E"
title="[EM] Condorcet meeting" moz-do-not-send="true">km_elmet
at t-online.de </a><br>
<i>Mon Aug 28 12:37:50 PDT 2023</i>
<ul>
<li><b>Messages sorted by:</b> <a
href="http://lists.electorama.com/pipermail/election-methods-electorama.com/2023-August/date.html#4835"
moz-do-not-send="true">[ date ]</a> <a
href="http://lists.electorama.com/pipermail/election-methods-electorama.com/2023-August/thread.html#4835"
moz-do-not-send="true">[ thread ]</a> <a
href="http://lists.electorama.com/pipermail/election-methods-electorama.com/2023-August/subject.html#4835"
moz-do-not-send="true">[ subject ]</a> <a
href="http://lists.electorama.com/pipermail/election-methods-electorama.com/2023-August/author.html#4835"
moz-do-not-send="true">[ author ]</a> </li>
</ul>
<hr>
<pre>On 8/28/23 19:24, Forest Simmons wrote:
><i> For practical purposes, this appeals to me the most so far.
</i>><i>
</i>><i> But the question remains about how to determine the number N.
</i>><i>
</i>><i> Why not just use the number ranked (or approved, as the case may be) on
</i>><i> the average primary ballot?
</i>
Here's a similar approach with an idea to preserve a kind of clone
independence:
Use STV, but don't eliminate candidates when they're elected, just
reweight the ballots according to surplus instead.
When a candidate is elected again, he only appears once in the final
outcome, but the number of candidates in the outcome is reduced by one
instead. In effect, the duplicate election leads to the election of a
"hole" that takes up a spot without assigning any candidate to that spot.
Say N = 5, so that the Droop quota is 1/6. Then a candidate with
above-majority support (say 1/2 + epsilon) gets three such quotas, and
is elected three times: once to get into the finalist set, and twice
more to reduce the number of other candidates from four to two.
The idea is that if the candidate were to be cloned, then these clones
would occupy three spots of the outcome, so the result is the same; just
in one case, there's only one winner from that bloc and two "holes",
while in the other case, there would be three winners from the bloc.
I would probably reserve one of the five spots for the primary CW,
though. Ideally it would use a proportional ordering or a pairwise STV
variant, but then we're moving into "deluxe, complex method" territory.
</pre>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>