<div dir="ltr"><div>Thanks everyone for weighing in on this topic, and thanks Kristofer for fixing up my previous inaccurate summary on electowiki.  After Kristofer made his changes, I followed up with some shuffling of the prose in the body of the article.  It's far from perfect, but I think the article is better than it was last week:</div><div><a href="https://electowiki.org/wiki/Summability_criterion" target="_blank">https://electowiki.org/wiki/Summability_criterion</a></div><div><br></div><div>We should also consider making similar changes over on English Wikipedia, since that article hasn't gotten a lot of love since I restored it in January 2022.</div><div><a href="https://en.wikipedia.org/wiki/Summability_criterion" target="_blank">https://en.wikipedia.org/wiki/Summability_criterion</a></div><div><br></div><div>I suspect I'm not the only one who has conflated the "Summability criterion" and the "Consistency criterion".  Here's a link to the latter:</div><div><a href="https://electowiki.org/wiki/Consistency_criterion" target="_blank">https://electowiki.org/wiki/Consistency_criterion</a></div><div><div><div>If I'm right, it may be useful to explain the relationship between "consistency" and "summability" to electowiki readers.<br></div></div><div><br>Even as a longtime advocate for Condorcet compliance, I have to concede that approval voting beats strict Condorcet winner compliance with regards to consistency and simplicity.  It's much easier to imagine real-time results consumable by mainstream voters from talking-head newscasters as they report on election night than it is to imagine what this looks like with methods that fail the consistency criterion.</div><div><br></div><div>Rob<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 7, 2023 at 2:51 AM Kristofer Munsterhjelm <<a href="mailto:km_elmet@t-online.de" target="_blank">km_elmet@t-online.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 10/7/23 06:26, James Faran wrote:<br>
> I'm not certain about the second item.  My worry is the following method <br>
> that someone must have thought of before me and rejected.<br>
> <br>
> Given any single ballot, we can use it to create the pairwise matrix.  <br>
> The entries will be +1, 0, or -1. From that pairwise matrix we can <br>
> reconstruct the preference order given on the ballot. Concatenate all <br>
> such pairwise matrices. This "summary", an n by n by v array, has size <br>
> on the order of n^2*v, where n is the number of candidates and v the <br>
> number of voters. The combination of these is by concatenation in the <br>
> "v" direction of the array.  This is quadratic in n (just as good as a <br>
> pairwise method) and linear in v (pairwise methods are logarithmic in <br>
> v). Plurality is linear in n and logarithmic in v (when v gets bigger we <br>
> just have to increase the number of digits used to describe the totals). <br>
> The point is that this method transfers complete ballot information, yet <br>
> clearly is not a method one would want to use.  And we certainly, in <br>
> avoiding discussion of polynomial growth, don't want to suddenly need to <br>
> explain logarithmic growth.<br>
> <br>
> As v has a tendency to get bigger than n, I think "polynomial in n" and <br>
> "logarithmic in v" might be a good standard.  (A rough calculation leads <br>
> me to believe this method beats just listing the number of ballots of <br>
> each of the n! types when (n-2)! > v, so is only really a help when n is <br>
> large.  For 10^7 voters, I think n=14 might do it.)  All in all, as it <br>
> stands the second point is good enough. We'd just want to avoid <br>
> responding to a "What does that mean?" question with "You don't want to <br>
> know," or "You wouldn't understand." However, for studying the question, <br>
> a more precise definition is needed, lest every method be "summable".  <br>
> Should the amount of calculation time needed to analyze the "summary" <br>
> come into it?<br>
<br>
Yes, the current mathematical standard defined in the Electowiki article <br>
is "polynomial in candidates, logarithmic in voters" for just the reason <br>
you mentioned: the number of voters increases much more quickly than the <br>
number of candidates. Strictly speaking, I suppose polylogarithmic could <br>
also work, but nobody has ever made such a summary so I shouldn't <br>
complicate matters too much.<br>
<br>
Perhaps something like "should grow slowly in the number of candidates <br>
and even more slowly in the number of voters". But even that's adding <br>
more detail to a brief summary.<br>
<br>
In any case, my idea was that the summary should be brief, and then <br>
questions like "what does *slow* mean" can be answered by pointing at <br>
the mathematical definition, or by a longer elaboration that first <br>
explains the justification (e.g. "there will be more voters than <br>
candidates"), and then does a rigorous definition.<br>
<br>
-km<br>
</blockquote></div>