No, this isn’t a post about politics, sorry, it’s just a post about voting theory.
As you might have noticed (and if not, this is the post announcing it), I have a book out! It’s called Voting by Example and is about the complexities of voting and why different voting systems might be interesting. You should go buy it.
But this isn’t just an ad post for the book, it’s about something else: How I came up with the examples in this book.
At its core is the following example. We have a student election where there are four candidates are running for class president. Each student casts a vote ranking the four candidates in order of most to least preferred.
The votes are as follows:
- 32% of students voted Alex, Kim, Charlie, Pat
- 27% of students voted Charlie, Pat, Kim, Alex
- 25% of students voted Pat, Charlie, Kim, Alex
- 16% of students voted Kim, Pat, Alex, Charlie
The point of this example is that each of four different ranked voting systems give a different answer:
It’s also constructed to have a minimal number of voting blocs, though it’s minimum amongst a slightly more specific set of elections than just those satisfying the above conditions.
Roughly what this means is:
- Alex has the most first choice votes
- When compared pairwise with any other candidate, the majority prefer Charlie
- Pat wins a complicated procedure where people iteratively drop out depending on who is the favourite of the remaining candidates amongst the fewest voters
- If you give people a score of 3 for each voter who ranks them first, two for each who ranks them second, and one for each who ranks them third, then Kim has the highest score.
If you want to know more than that I recommend the relevant Wikipedia links above, which are all very approachable.
The significance of this is that each of these is a popular (either in practice or amongst electoral theorists) way of saying who should be the winner. So the situation ends up being rather complex to decide.
But this isn’t a post about the significance. This is a post about how I constructed the example.
Historically I’ve generally created example elections with Hypothesis or a similar approach – randomly fuzzing until you get a result you want – but that wasn’t really going to work very well here due to the rather complicated set of constraints that are hard to satisfy by accident.
So I instead turned to my old friend, integer linear programming.
The idea of integer linear programming (ILP) is that we have a number of variables which are forced to take integer values. We can then impose linear constraints between them, and give a linear objective function to optimise for. For example we might have three variables \(v_1, v_2, v_3\) and the following constraints:
- \(v_1, v_2, v_3 \geq 0\)
- \(v_1 + 2 v_2 + 3 v_3 \leq 5\)
And then try to maximise \(v_1 + 2 v_2 + 4 v_3\).
Given a problem like this we can feed it to an ILP solver and it will spit out a solution. If we do that, it will tell us that an optimal solution for this problem is \(v_1 = 2, v_2 = 0, v_3 = 1\).
A lot of problems can be nicely turned into ILP problems, and there are some fairly good open source ILP solvers, so it’s often a nice way to solve complex combinatorial problems.
So how do we turn our election rigging problem into an integer linear program?
The key idea is this: 4! isn’t very large. It’s only 24. 24 is tiny from an ILP point of view.
This means that there’s no problem with creating a variable for each of the possible votes that someone could cast, representing the number of people who cast that vote. That is, we create integer variables \(v_p\) indexed by permutations with the constraints:
- \(\sum v_p = 100\)
- \(v_p \geq 0\)
Then the value of e.g. \(v_{(0, 1, 2, 3)}\) is the number of people who cast the exact vote \((0, 1, 2, 3)\) (or, by name, Alex,, Charlie, Pat, Kim).
We then use a trick to get nicer examples, which is that we try to minimise the number of non-zero votes. The idea is to create variables which, when minimised, just look like markers that say whether a vote is non-zero or not.
So we create supplementary 0/1 valued integer variables \(u_p\) with the constraints that \(v_p \leq 100 u_p\), and set the objective to minimise \(\sum u_p\). Then \(u_p\) will be set to \(0\) wherever it can be, and the only places where it can’t are where \(v_p\) is non-zero. Thus this minimises the number of voting blocs.
So that’s how we create our basic ILP problem, but right now it will just stick 100 votes on some arbitrary possible ballot. How do we then express the voting conditions?
Well, lets start with the plurality and Borda scores. These are pretty easy, because they constitute just calculating a score for each candidate for each permutation and adding up the scores. This means that the scores are just a linear function of the variables, which is exactly what an ILP is built on.
Victory is then just a simple matter of one candidate’s score exceeding another. You need to set some epsilon for the gap (linear programming can’t express \(<\), only \(\leq\)), but that’s OK – the scores are just integers, so we can just insist on a gap of \(1\).
The following code captures all of the above using Pulp, which is a very pleasant to use Python interface to a variety of ILP solvers:
The idea is that the additive_scores parameter takes a list of scoring functions and a partial list of winners given those functions and returns an election producing those orders.
So if we run this asking for the plurality winners to be (0, 1, 2, 3) and the Borda winners to be (3, 2, 1, 0) we get the following:
>>> build_election(4, 100, [
(lambda p, c: int(p[0] == c), (0, 1, 2, 3)),
(lambda p, c: 3 - p.index(c), (3, 2, 1, 0))])
[((0, 3, 1, 2), 35), ((1, 2, 3, 0), 34), ((2, 3, 0, 1), 31)]
So this is already looking quite close to our starting example.
Creating a Condorcet winner is similarly easy: Whether the majority prefers a candidate to another is again just an additive score. So we just need to add the requisite \(N\) constraint that our desired Condorcet candidate wins.
if condorcet_winner is not None:
victories = {
(i, j): lpsum(
v for p, v in variables if p.index(i) > p.index(j) )
for i in candidates
for j in candidates
}
for c in candidates:
if c != condorcet_winner:
problem.addConstraint( victories[(condorcet_winner, c)] >=
victories[(c, condorcet_winner)] + 1
) |
if condorcet_winner is not None:
victories = {
(i, j): lpsum(
v for p, v in variables if p.index(i) > p.index(j) )
for i in candidates
for j in candidates
}
for c in candidates:
if c != condorcet_winner:
problem.addConstraint( victories[(condorcet_winner, c)] >=
victories[(c, condorcet_winner)] + 1
)
If we run this to force the Condorcet winner to be \(1\) we now get the following:
>>> build_election(4, 100, [
(lambda p, c: int(p[0] == c), (0, 1, 2, 3)),
(lambda p, c: 3 - p.index(c), (3, 2, 1, 0))],
condorcet_winner=1,
)
[((0, 3, 1, 2), 28),
((1, 2, 3, 0), 27),
((2, 1, 3, 0), 24),
((3, 2, 0, 1), 21)]
This is pretty close to the desired result. We just need to figure out how to set the IRV winner.
This is a bit more fiddly because IRV isn’t a simple additive procedure, so we can’t simply set up scores for who wins it.
But where it is a simple additive procedure is to determine who drops out given who has already dropped out, because that’s simply a matter of calculating a modified plurality score with some of the candidates ignored.
So what we can do is specify the exact dropout order: This means we know who has dropped out at any point, so we can calculate the scores for who should drop out next and add the appropriate constraints.
The following code achieves this:
if irv_dropout_order is not None:
remaining_candidates = set(candidates)
for i in irv_dropout_order:
if len(remaining_candidates) <= 1:
break
assert i in remaining_candidates
allocations = {j: [] for j in remaining_candidates}
for p, v in variables:
for c in p:
if c in remaining_candidates:
allocations[c].append(v)
break
loser_allocations = sum(allocations.pop(i))
remaining_candidates.remove(i)
for vs in allocations.values():
problem.addConstraint(loser_allocations + 1 <= sum(vs)) |
if irv_dropout_order is not None:
remaining_candidates = set(candidates)
for i in irv_dropout_order:
if len(remaining_candidates) <= 1:
break
assert i in remaining_candidates
allocations = {j: [] for j in remaining_candidates}
for p, v in variables:
for c in p:
if c in remaining_candidates:
allocations[c].append(v)
break
loser_allocations = sum(allocations.pop(i))
remaining_candidates.remove(i)
for vs in allocations.values():
problem.addConstraint(loser_allocations + 1 <= sum(vs))
And running this we get the following:
>>> build_election(4, 100, [
(lambda p, c: int(p[0] == c), (0, 1, 2, 3)),
(lambda p, c: 3 - p.index(c), (3, 2, 1, 0))
], condorcet_winner=1, irv_dropout_order=(3, 1, 0, 2))
[((0, 3, 1, 2), 31),
((1, 2, 3, 0), 27),
((2, 1, 3, 0), 25),
((3, 2, 0, 1), 17)]
This isn’t quite the same example in the book (the first bloc has one fewer vote which the last bloc got in this), because the book example had a bit more code for optimizing it into a canonical form, but that code isn’t very interesting so we’ll skip it.
Here’s the full code:
I’m constantly surprised how nice integer linear programming ends up being for constructing examples. I knew I could do the Borda and plurality scores – that’s in fact the example that motivated me trying this out at all – but although I find it obvious in retrospect that you can also fix the Condorcet winner it definitely wasn’t a priori. The fact that it’s easy to also calculate the IRV dropout order was genuinely surprising.
This is also a nice example of how much fun small n programming can be. This isn’t just an O(n!) solution – it generates a problem of size O(n!) and then feeds it to a solver for an NP-hard problem! in principle that should be catastrophic. In practice, n is 4, so who cares? (n=4 is about the limit for this too – it just about works for n=5, and for n=6 it doesn’t really).
I also find it somewhat surprising how much freedom there is to get different results from different voting systems. I was motivated to do some of this by The ultimate of chaos resulting from weighted voting systems, so I knew there was a fair bit of freedom, but I was somewhat expecting that to be a pathology of weighted voting systems, so I’m still a little surprised. I guess there’s just quite a lot of room to play around with in a 24-dimensional simplex.
Which brings me to my final point: When you’re trying to understand what is possible in a domain, this sort of example generation focused programming is very useful for exploring the limits of the possible and building your intuition. I feel like this isn’t a thing people do enough, and I think we should all do more of it.
I also think you should buy my book.
(Or support my writing on Patreon)