# 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:21:08 CDT

On Apr 30, 2004, at 3:53 PM, Alan Dechert wrote:
> I happen to feel compression would be okay. It's a trade
> off--transparency
> versus economy. The number of bits encoded could be increased at least
> three-fold (maybe ten?) with compression for a given length of barcode.

I think 3X, let alone 10X, is unlikely as a compression ratio for
ballot barcodes. I guess we need some empirical data and a concrete
compression technique before we can really determine the answer.

One thing to keep in mind, however, is that almost all common
compression techniques have different compression rates depending on
the particular data being compressed. But we need to handle the *worst
case* in the technique we use. "Typical" compression ratios are of no
value to us.

That is, suppose that the "most common" voting patterns really are
compressible by 10X. We might naively start planning a choice of
barcode, font, etc. based on that 10X rate. But there might be one
particular "weird," but legal, voting pattern that winds up
incompressible under the chosen compression (or only compressible at
some much lower ratio).

If we find barcodes can be no more than N inches, or L digits or
whatever, and the weird incompressible vote doesn't fit in the allowed
inches, then we've just disenfranchised that "weird" voter. VERY not
good!

So in evaluating any compression technique, we need to PROVE
mathematically that every legal vote will be compressed by the minimal
ratio we rely on. In general, I find it easier to handle this problem
at the first-pass level of how votes are encoded as digits than at a
second-pass of generic compression (e.g. LZW/gzip style).

Yours, David...
==================================================================
= 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