In exploring the ballots available for download from Stack Exchange elections, the Code Review community came across some unexpected values in the ballot data.


First, the specification, as far as we can tell, for the *.blt file indicates that each ballot line indicates a weight/count, and then the id's of the candidates that were part of that ballot, followed by a 0. For example, an entry:

1 7 4 9 0

would indicate 1 vote for first-choice candidate 7, then 2nd choice candidate 4, and third-choice candidate 9.

The evidence for this specification comes from two places. Here, Jeff Atwood describes the format. A second reference is here in google code: BltFileFormat I am uncertain of how official that reference is, but it agrees with Jeff.

What is clear is that if a voter only chooses a subset of the available candidates, that their ballot will be 'shorter' than other ballots. For example, in Jeff's answer, there is the data:

1 1 4 2 3 0  # The first number is the ballot weight (>= 1).
1 1 2 4 3 0  # The last 0 is an end of ballot marker.
1 1 4 3 0    # Numbers in between correspond to the candidates
1 3 2 4 1 0  # on the ballot.
1 3 4 1 2 0
1 3 4 1 2 0  # Chuck, Diane, Amy, Bob
1 4 3 2 0
1 2 3 4 1 0  # last ballot

The 3rd and 7th lines indicate ballots which do not have a full complement of candidates voted for.

Herein lies the problem. In the SE election data, there are 'occasional' references to candidate 0, who does not exist, and should not exist. Here are the first 10 or so "odd" ballots from the 2015 SO election (there are 206 odd ballots (pastebin) and more than 27,000 ballots in total):

27: 1 0 7 0 0
384: 1 0 9 2 0
498: 1 0 4 7 0
508: 1 0 4 0 0
833: 1 3 0 5 0
964: 1 0 8 0 0
970: 1 1 0 9 0
1016: 1 10 0 9 0
1103: 1 5 0 6 0
1230: 1 0 5 0 0

The number before the colon is the ballot line number from the above file/dataset (direct-link here)


Given the above, it is somewhat logical to assume that the odd-valued ballots are a result of voters not choosing all of the 1st, 2nd, and 3rd choice candidates. I.e. a voter who only selected a 2rd-choice candidate (candidate 5) may have a ballot like 1 0 5 0 0

While that is a logical assumption, it is also non-conformant to the specification. That vote should be registered as 1 5 0

  • So, is our assumption correct that the system is producing a 'bad' file for some votes as a result of not choosing all candidates?

  • If not, why are there 0-values in the candidate-space for ballots?

  • should the ballot system be audited to ensure that votes are not being 'spoiled' inadvertently (i.e. are we sure that the OpenSTV tool can handle this "bad data" appropriately)?

  • 2
    No harm in reviewing the code. Doesn't appear that this is a problem for OpenSTV, whose parser is line-based and silently converts all but the last 0 to -1, which it uses internally to indicate a skipped ranking. Might be a problem for other parsers, particularly those that are not line-based.
    – Shog9
    May 14 '15 at 2:55
  • In my own parsing of the format I just assumed that 0 meant 'skipped', or the user did not use their 1st or 2nd vote option. The numbers I got from that certainly fit the OpenSTV election results. May 14 '15 at 7:47

So, is our assumption correct that the system is producing a 'bad' file for some votes as a result of not choosing all candidates?


i.e. are we sure that the OpenSTV tool can handle this "bad data" appropriately?

Based on the OpenSTV 1.7 source, at least, this is a permissible format for the .blt file (as an extension), albeit accidentally. The correct value for a skipped ranking is intended to be -1, but due to how the loader works, ranking a candidate 0 will result in -1 anyway due to an indexing conversion:

ballot.append(int(c) - 1)

The question then becomes what happens to skipped rankings in a MeekSTV count and whether this is an issue…I'm fairly certain that it isn't, and that running the election with ballots containing skipped rankings just evicts those entries, effectively moving the remaining rankings up in position.

For compatibility purposes it might be nice if the file was produced in the standardized format, but failing that the zeros should likely be converted to -1 to avoid confusion.

  • 3
    Interesting, I will make sure that all values are -1 instead of 0 for votes with an unknown rank to avoid confusion in the future. Excellent detective work! May 14 '15 at 4:53
  • If would be nice if the SE user interface for elections enforced voting in the correct order such that this problem was avoided completely. Oct 20 '20 at 17:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .