Re: How big could a bar code be if a bar code could be big?

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Fri Apr 30 2004 - 15:56:20 CDT

On Apr 30, 2004, at 4:37 PM, Alan Dechert wrote:
> However, I don't necessarily agree that we have to use one scheme that
> works
> for every situtation. Keep in mind that on our demo ballot, more than
> half
> the bits are for one contest -- the ranked preference contest, "County
> Commissioner."

But look at my post:

Where I show that the numbers of possible votes in ranked preference
contests really does get quite big quite quickly. I actually don't
even give an 8-position rank in the table (but you can use the script
to generate it). But it works out to 109601 DISTINCT valid votes.
Which is 17 bits of actual entropy.

Everything that isn't ranked preference has much less entropy, of

Even here though, I think it is best to think in terms of creating
optimal vote encodings in the first place rather than in terms of
hoping for the best when you run gzip over a highly non-optimal
encoding. For example, figure out an algorithm to encode those 109601
possible votes in *exactly* 17 bits all the time--then we know we need
no more and no less than 17 bits on the ballot (or maybe loosen it to
18 or 20 bits to make it easier... which is still better than the
approx 56 bits the current encoding uses). The algorithm for encoding
will be more complicated, but we need not worry about the
compressibility of a particular vote.

> What if we find that we can use a 1-d scanner that will work in 99.9 %
> of
> the circumstances. Say, in San Francisco, they go for IRV and they
> have big
> ballots so we need a 2-d scanner. What if the 1-d works in 2,218
> counties
> while it doesn't work in one.

Sure... I agree that we can customize the choice of barcode per county.
  There are many other features of ballots that will be customized too,
so no harm in this.
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
Received on Fri Apr 30 23:17:27 2004

This archive was generated by hypermail 2.1.8 : Fri Apr 30 2004 - 23:17:29 CDT