Re: Ranked Choice Voting -- San Francisco Style

From: Steve Chessin <steve_dot_chessin_at_sun_dot_com>
Date: Wed May 05 2004 - 03:19:16 CDT

>From Tue May 4 20:38:01 2004
>To: (OVC)
>Subject: [voting-project] Ranked Choice Voting -- San Francisco Style
>Date: Wed, 05 May 2004 03:37:48 +0000
>I called the San Francisco Department of Elections and talked with
>someone named Anita. While she doesn't have all the details, what she
>did have enabled me to update the Data Model I proposed and develop
>some suggestions for the Process Model (or Programming Specs or
>whatever we'll call it).
>The Data Model changes were easy.
>1) Add one data item, Ranked_Choice_Lim, to the contest definition
>table (CFO_Cont). Each contest that allows Ranked Choice Voting will
>have a number greater than one, which is the maximum number of ranked
>choices per ballot for this contest.
>2) Add one data item, Ranked_Choice_Num, to the Ballot Segment for
>Candidate For Office (BS_CFO).
>The Process Model is complicated considerably more by this. Here are
>my suggestions:
>1) Materialize Ballot on Screen (Or whatever we'll call it) will need
>to allow for ranked choice numbers rather just check marks or x's for
>voters' choices.

The typical touch-screen UI is that the first person you select is your
first choice, the second one is your second choice, etc. I've seen two
different deselection models: Deselecting a candidate in the middle
move everyone below up by one (that is, if you select A, B, C in that
order, and then deselect B, A stays your first choice and C becomes
your 2nd choice); and deselecting a candidate in the middle clears
everyone below that candidate (that is, if you select A, B, C in that
order, and then deselect B, A stays as your first choice and C is also
deselected). The former behavior is probably preferable.

>2) Checking for overvotes and undervotes will need to refer to the
>ranked choice information.

Unless the jurisdiction allows for duplicate rankings (most don't, and
it certainly complicates UI design; in particular, San Francisco does
not), the UI can ensure that no two candidates are assigned the same
ranking. The UI can also prevent overvoting (in case there is a limit
as to how many you can rank; ideally, there wouldn't be, but that's a
jurisdiction policy decision). I'm not sure how undervoting applies;
there's nothing wrong if a voter just wants to rank one person.

>3) Counting Votes By Contest -- With ranked choice voting, count only
>those ballots with Ranked_Choice_Num = 1.

While this probably doesn't apply to OVC/EVM, for optical-scan ballots
you probably first want to "normalize" them, in case the voter skips a
number. (For example, I might mark A as 2 and B as 3, and not give
anyone the "1" ranking. The ballot tabulation program would want to
normalize the data before applying the counting algorithm, since my
vote for A should count as a first choice.)

>4) Finding Ranked Choice Majority -- If no candidate wins a majority,
>copy all votes for this contest to a working area and switch to
>decision support logic. The candidate with the lowest vote total is to
>be eliminated. (What if tie for last -- TBD).

That's up to jurisdictional rules. There are two main methods:
- Eliminate the tied person who had the fewest votes in the immediately
preceeding round of counting. Apply recursively. If the tie extends
into the first round, then choose one by lot.
- Always use lots to choose the person to eliminate. (I think this is
what San Francisco's rules are.)

Note that unnecessary tie-breaking can be eliminated by eliminating all
candidates who have no mathematical chance of winning. That is, if the
bottom N candidates have amongst them fewer votes than the next highest
candidate (N+1 from the bottom), then they can be all eliminated at
once. This means you usually won't have to break ties amongst a bunch
of write-ins who each have one vote.

>5) Eliminate a Ranked Choice Candidate -- To eliminate a candidate,
>delete all his 1st choice votes, mark the #2 choices on those ballots
>as #1, and cascade this logic to subsequent choices (3 becomes 2, 4
>becomes 3, etc). Count votes with Ranked_Choice_Num = 1 and check for
>majority. If still no majority, again identify lowest vote getter and
>repeat the process.

That's one way of doing it (and may be how San Francisco describes
their algorithm). Another way is to mark the candidate "defeated", and
as you process each ballot again, you count it towards the first
non-defeated candidate that has the highest ranking (lowest numerical
value) on that ballot.

A third way is you keep a linked list of the ballots by their current
first choice, with a total in the list head. (Emulates piles.) When a
candidate is eliminated, you move each ballot to the list of the next
non-defeated candidate on that ballot, and increment the list-head
counter (emulates moving the ballots to the appropriate piles).
(The ballot itself could be a linked list, starting with first choice,
second choice, etc., and a pointer in the list-head to the current
choice. Or you could use an array and array index.)

But they are all conceptually the same, and should all (had better)
produce the same result.

>I hope this helps. If anyone else knows of anything else like this,
>let me know. If there are rules, I can model it.

I suggest you visit these links:

You can also find open-source freeware at

= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Mon May 31 23:17:14 2004

This archive was generated by hypermail 2.1.8 : Mon May 31 2004 - 23:18:15 CDT