[EM] Rank Codes
Kristofer Munsterhjelm
km_elmet at t-online.de
Sat Feb 13 08:15:10 PST 2021
On 13/02/2021 03.29, Forest Simmons wrote:
> It pains me to see all of the ranked ballot proposals that unnecessarily
> limit preferences to three or four alternatives because of ignorance of
> simple higher resolution ballots that can be easily marked and read (by
> hand or by machine) without ambiguity or confusion from poorly formed
> characters, stray marks, etc.
I have an impression that the problem is not real, but imagined: that
it's possible to do unlimited ranked ballots in practice without much
difficulty. Otherwise, the jurisdictions that currently use STV would
have encountered the problem and dealt with it already.
So the problem is more one of perception: it seems obvious that unclear
ballots are going to be hard to read, regardless of whether they
actually will. And so, as a precautionary measure, the method gets
limited to a few ranks.
(There may also be technology-specific limitations, e.g. the
jurisdiction in question uses mechanical voting machines that can't be
adapted to more than this many ranks.)
> A method that allows only three or four candidates to be ranked cannot
> satisfy clone independence ... the only indispensable justification for
> scrapping First Past the Post Plurality. And (beyond that) it
> exacerbates the biggest IRV/STV/RCV defect, the high likelihood that
> one's choices will be completely exhausted before the final rounds
> unless you rank lesser evils at the expense of alternatives you like
> better, because of ranking limitations that highlight the effect of
> premature eliminations.
>
> It is alleged that because of ambiguous handwriting and lack of room for
> more than a few "bubbles," only a handful of distinct ranks can be allowed.
>
> But what if each bubble has a different value?:
>
> [8] [4] [2] [1]
>
> The rank of a candidate is the sum of its darkened bubble values ... a
> number between zero and fifteen.
I think these would confuse quite a few voters.
I'd probably just go with ordinary numbers and be fairly confident it's
going to work out. But if the problem is indeed one of perception, then
just saying "don't sweat it" isn't going to convince anyone who's sure
there will be problems.
Perhaps a study on ballot rejection rates would help provide evidence
that it works well most of the time? I seem to recall reading on
Reddit's EndFPTP forum that ballot spoilage rates are about the same for
FPTP and STV.
> Suppose that there are to be 26 candidates, then instead of indicating
> their relative ranks with mere numbers, you can order them with standard
> alpha numeric code words ... Alpha1, Bravo2, Charlie3, Delta4, Echo5,
> Foxtrot6, ... Victor22, Whiskey23, Xray24, Yankee25, Zulu26. So the
> military already solved the ambiguity/ "noisy channel" commuunication
> problem in the early days of Morse code.
>
> These 26 code words cannot be confused with each other no matter how
> illegible the hand writing.
Of the two suggestions, I think I prefer this one. You could make this a
minimal change by saying that a voter may use either ordinary numbers or
codewords, so that voters who want to be extra sure that their ballots
will be counted properly can use the codewords, while others may opt out
if they think it's not worth the hassle.
> These suggestions are intended for absentee and other mail-in ballots
> ... electronic voting machines should allow in person voters to drag the
> names into a list in any order, and then print out paper copies for
> voter and precinct receipts.
I'd prefer voting machines to be "Expensive Pencils" where the voter can
input preferences and have a paper ballot printed out, and where that
paper ballot is what gets counted. A voting machine is opaque; a
printout is not.
To mitigate chain voting, the machine could show the printout behind
glass and deposit it directly into either the trash or the ballot box
depending on the voter's choice. In addition, such a scheme would keep
fingerprints and DNA off the ballot paper.
More information about the Election-Methods
mailing list