Re: Large Ballot Redux

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Thu Jun 03 2004 - 11:03:02 CDT

On Jun 3, 2004, at 11:18 AM, Alan Dechert wrote:
> I guess we didn't get a direct answer from David on that, but I'm
> pretty
> sure it would be no sweat even for 1-D barcodes. Most of the 76 races
> would
> take only one bit each; a few would take 2 or 3 bits. My guess is ~100
> bits.

If the contests are judicial confirmation or initiatives, there are
actually three possible votes: Yes; No; No Preference. If we break
contests at bit boundaries (which as has been discussed, is not
strictly required, but makes debugging and remediation a LOT easier),
that's two bits for each such contest.

If the contests are between two candidates, that usually amounts to
four possible votes: Smith (listed); Jones (listed); Write-In; No
Preference. Fortunately, that still fits in two bits, maintaining bit
boundaries. This assumes that write-ins are just flagged as such in
the barcode, the name written in is not directly encoded (it requires
visual inspection of those ballots).

So an election that was 76 apparently Yes/No contests, would actually
require 152 bits, using bit-boundaries, i.e. 76*2. Even if we didn't
respect bit boundaries, we'd need 121 bits, i.e. Log2(3^76).

I didn't do the work of going through the actual 76 races (that why I
made the tool PUBLIC after all :-( ... and then even created a friendly
web interface to it!). But a few of them had more than two candidates,
so throw in a few more bits there, maybe 160-170 bits using
bit-boundaries. And even ignoring bit boundaries, many of the contests
are 4-option, not 3-option (e.g. Smith vs. Jones, not Judge Brown
Yes/No), which adds some bits to the absolute optimal encoding. So
maybe that's 140 bits rather than 121.
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Wed Jun 30 23:17:04 2004

This archive was generated by hypermail 2.1.8 : Wed Jun 30 2004 - 23:17:29 CDT