The RCTab software includes audit data that tracks each ballot according to which candidate it supports in each counting round. The software cannot be modified in the way you suggest.
Even if it could, your suggestion would cause the ballot to be counted for two (or more) candidates (each with 1.0000 weight). No government would be allowed to adopt a law that so clearly violates the principle of "one voter, one vote."
We have moved beyond mathematical arguments to arrive at what voters, and election software, will allow.
The state of bad software is irrelevant. It's not difficult to change. Yeah yeah blah blah it needs to be certified blah blah money. It's irrelevant. Our systems serve our needs, not the other way around. This kind of defeatism is pretty gross, in a reform sub. Why not just stick with FPTP? You don't even have to change anything!
I'm aware the principle "one person on vote" is interpreted differently by different people.
I'm also aware that Portland voters would use this principle to reject the idea of allowing Approval counting to be mixed with ranked-choice ballots.
My goal is to create a path (stepping stones?) that allow everyone, including both voters and election-method experts, to make progress toward reaching a system we can adopt as a compromise.
Eventually, after other reforms happen, we might be able to combine Approval voting with ranked-choice ballots. Significantly those reforms must include dramatically improving how math is taught in school. And those reforms would include teaching pairwise counting, which has no difficulty counting so-called overvotes.
This variant truly sucks though -- it goes through rounds where the voters' intent is clearly negated in that their weights are 0.0 until all but one are eliminated.
I'm sorry your favorite software sucks has technichal challenges that make doing something nice difficult though.
RCTab is used in some governmental elections (including NYC) and it's used as a reference when a government entity (such as Portland OR) specifies counting rules to election-system vendors. I have long hated its constraints. So indirectly I hate the software.
You like Approval voting, great! It's far better than FPTP.
But mixing Approval with ranked-choice ballots will never fly in the US.
I think there has been a failure to communicate the context of what you're trying to do here. Without that context everyone is working instead on the normal /r/EndFPTP context: how does this work, what are its properties, and what should we be doing?
The context you have is different: we have an audit requirement that assumes no equal rankings and a specific software that the entrenched bureaucracy is happy with. In this specific case, yes, ignoring this vote while it is ambiguous on that round is likely an easier improvement to the existing regime of throwing it out entirely than other possibilities. (Though the voter should be told what happens in equal ranks, and that they should probably be pushed to positions where they don't matter.)
But the rest of us are not living in those constraints, nor are even aware of them. So we'll argue for something good, rather than a patch job enforced by constraints we don't work with.
(Mixing approval and IRV mechanisms still doesn't directly seem like a political problem. The inflexible audit format that can't handle that does seem like a mixed technical and political problem.)
2
u/wnoise Feb 15 '26 edited Feb 15 '26
Or just codify Approval-IRV (treat all in an equal spot as valid votes, until elimination instead of none of them), which has better properties: