[EM] Simplest Condorcet method to hand count?

[Etjon Basha]

But Kristofer,

Isn't the cheeky system you ponder in your first footnote just...FPP?

I jest, I jest.

On Sun, 25 May 2025, 9:21 pm Kristofer Munsterhjelm, <
km-elmet at munsterhjelm.no> wrote:

> On 2025-05-24 07:22, Etjon Basha via Election-Methods wrote:
> > Thank you all, gentlemen
> >
> > I greatly enjoyed the discussion and FWIW come out of it with a greater
> > appreciation of Condorcet.
> >
> > A summary for my own benefit: it seems like a hand-count makes one chose
> > between two counts for races with n candidates.
> > In all, there seems to be no faster and more practical way than a
> > pairwise count to compute a Condorcet winner manually.
>
> The only way I see to break this barrier is to use randomness. You could
> randomly sample ballots if the complexity is prohibitive. E.g. you could
> count a random pairwise contest from each ballot. But then you need a
> trusted way to generate randomness.
>
> Theoretically, you could even do this on the front-end: ask each voter
> his preference for a randomly chosen pairwise contest X>Y. This is a
> very simple ballot and would leave the voter to only have to consider
> two candidates.[1] However, it would be unfamiliar and probably wouldn't
> be received well: even in the best case, you've replaced voters having
> to trust a machine count with voters having to trust your source of
> randomness, and if the race has a few very clear frontrunners, the
> majority of the voters who don't get asked about any frontrunner contest
> might feel cheated out of their opinion.
>
> But deterministically for Condorcet, I think v voters times n candidates
> is the best you can do (at least without seriously thinking outside the
> box). Because suppose otherwise, that you only check (n-1) candidates.
> Then it's possible that the candidate that you didn't check is the
> actual CW. There may be heuristics - e.g. if someone has a majority of
> the first preferences, that candidate is the CW - but they won't always
> hold.
>
>
> On a related note, I have been thinking about how to formally prove that
> a given method has a minimum degree of summability, or that for, say,
> thre candidates, it must know the value of (e.g.) five variables. Such
> an approach could show that, yes, you need n pairwise counts for every
> known method. (It could also disprove it, but that would be more
> surprising.)
>
> For concrete methods that are always decisive, this becomes a linear
> algebra problem.[2] I haven't found a way to solve this problem,
> however. There's an obvious upper bound using separating hyperplanes,
> but to my knowledge it's just that - an upper bound.
>
> The problem for methods that pass some criteria is even harder. For
> instance, I suspect that determining the innermost mutual majority set -
> the set of candidates that methods passing mutual majority must elect
> from - is not summable. But there are lots of methods that do pass
> mutual majority and *are* summable. I would be surprised if my intuitive
> hunch for Condorcet were to be disproven, though.
>
> -km
>
> [1] A fun theoretical system for people who consider rational ignorance
> a problem would be to assign every voter a defined pairwise contest a
> sufficiently long time before the election. Then the voter would only
> have to evaluate these two candidates, and could do so in more detail.
> But in practice, I don't think it would be accepted, and would require
> significant technology in its own right.
>
> [2] Each election can be characterized by a "vote vector" which lists,
> for each preference orde, how many voters voted that way. Then each
> candidate has a win region which is a union of convex polytopes in
> n!-dimensional space, and every point in A's win region has coordinates
> equal to a voting vector where the method declares A a winner. Then you
> have to find a minimal dimension projection so that no point in
> different candidates' win regions overlap after projecting all the win
> regions down to that dimension.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20250525/53472b11/attachment.htm>