Talk:Condorcet method: Difference between revisions
no edit summary
(→Write-in candidates: new section) |
No edit summary |
||
Line 26:
Can someone explain why this is the case? The reason I ask is because I'm guessing the issue is the following (and I have a solution to this): when you're counting each ballot, you have to record the pairwise preferences of that ballot against all write-in candidates. Yet, you can't know who all the write-in candidates are until you've finished processing all ballots. Therefore, you either have to do two rounds of counting the ballots, or skip write-ins.
If so, my solution is to use the [[Pairwise counting#Negative vote-counting approach]], wherein when each ballot is counted, you add any new write-in candidates found on it to the pairwise comparison matrix. [[User:BetterVotingAdvocacy|BetterVotingAdvocacy]] ([[User talk:BetterVotingAdvocacy|talk]]) 00:28, 14 May 2020 (UTC)
: Write-ins are more complicated in matrix Condorcet methods (than e.g. FPTP) because matrix counting itself is more complicated than FPTP. Some methods (e.g. Benham) solve the problem by not pretending to solve it: if the method isn't summable, there's no difficulty summing up anything.
: I think the problem resides in how truncation works in Condorcet, and that from the global perspective, every ballot that doesn't rank every write-in is a truncated ballot. Imagine a Condorcet variant that employed something like [[Range voting]]'s no-opinion option, so that if you rank A but fail to rank C, the method doesn't consider you to implicitly rank A above C, but to have no opinion on the A vs C (or C vs A) contest. Then handling write-ins would be no problem at all; you just add an A vs C cell to your global matrix whenever you find some precinct that has a ballot that ranks both A and C. In some sense, this is consistent: every ballot can then be imagined to be truncated above every candidate that were not part of the election anywhere, and that wouldn't change the matrix.
: However, as usually defined for Condorcet, a truncated ballot ranks every explicitly ranked candidate above every non-ranked candidate, and all of the latter candidates equal. From the global perspective, if only precinct x has a write-in (call him Joe), then every other precinct's ballot ranks Joe below everybody else (or coequal with every other unranked candidate if the ballot was already truncated). It's this distinction between "coequal last" and "below everybody else" that complicates precinct summation: if the election has candidates Alice, Bob, and Charlie, then a ballot in precinct y stating "Alice > Bob" is "really" Alice > Bob > Charlie = Joe, but a ballot in precinct y stating "Alice > Bob > Charlie" is actually Alice > Bob > Charlie > Joe.
: The negative vote count seems inelegant to me: a premature optimization, particularly in a software setting where a few more number increment operations is of little consequence.
: If, as I argued above, the problem is the distinction of last rank, then the algorithm that fixes it should make it clear that that's what the problem is. You really only need a count of how many times candidate X is explicitly ranked. Then you observe that for any incoming new write-in (e.g. Joe in precinct y when summing up x and y's totals), the value of any missing X>Joe cell for precinct y is the number of voters who explicitly ranked X in that precinct. No negative numbers needed, and this works both for equal-rank and strict ranking, as long as an all-equal ballot is considered to explicitly rank every candidate on it.
: As for voting software not implementing write-ins, that could just as well be due to convenience or UX matters. Nobody made it an issue of importance to have write-in support, and so it doesn't get included. [[User:Kristomun|Kristomun]] ([[User talk:Kristomun|talk]]) 13:23, 14 May 2020 (UTC)
| |||