Re: Re: bar code bit encoding

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Mon Sep 15 2003 - 16:00:23 CDT

Not quite out of town yet (tomorrow). Alan is on-track here

|You are working on the tabulation demo. Strictly speaking, the demo
|barcode has nothing to do with the tabulation demo.

The tabulation should expect to use data from vote-selection.xml files,
not use the barcode directly. The barcode is there only for
blind-accessibility, in terms of the vocalization of a printed ballot.
Well, it's also there to allow scanning of ballots in the event the
electronic results are damaged or challenged--but that will not be the
normal situation.

However, I do agree with Chris that a nibble-aligned encoding for the
barcodes is much preferable to one that requires computations on the
entire barcode as one big number. FWIW, nibble alignment amounts to the
same thing as digit-alignment for Code128C. The concern here is that we
will find that the barcode is wrong during our testing (even in the demo
phase).

Rather than simply have one big number that is generically different
from the real results, we can look digit-by-digit to see if a particular
vote is encoded right. E.g. maybe race 7, which is Pick5of10, gets
encoded wrong, but the others are OK... we know what to fix that way (my
example is off the top of my head, not per the ballot sample). My
recent "What needs to be done" note gave an example that seems
straightforward for a good encoding.

If something like Chris or I suggest bumps against the 60-digits (30
symbol) limit, we can give it up. But I don't think it will. Still,
I'll happily accept anything with actual code over anything without it.

| It's important to remember that compression system
| will not work well on very short lengths of data like ours.
|It may be that some readily available compression algorithms won't work with
|our data, we know others that will work.

Nah... what Chris listed really was theoretical limits for the different
race types. The stuff about how symbols/digits/characters break up is
dependent on the specific barcodes. But in terms of bit count, you
can't really compress past what he suggested.

Actually, that's not QUITE true. If certain votes are more common than
others, that decreases entropy across the set of ballots. But we aren't
interested in *average* compression, but in *worst case*... even
atypical vote selections need to fit on the ballot :-).

|Please, for the demo, let's not get too wound up about how many races
|we can handle or how many candidates or choices per contest we can
|handle.

That's right. Absolutely. If the production system needs to represent
absurd races, or absurdly many (i.e. California :-)), we might wind up
needimg a 2D barcode. But Code128 is good for the demo.

Yours, David...

--
 mertz@   _/_/_/_/_/_/_/ THIS MESSAGE WAS BROUGHT TO YOU BY:_/_/_/_/ v i
gnosis  _/_/                    Postmodern Enterprises         _/_/  s r
.cx    _/_/  MAKERS OF CHAOS....                              _/_/   i u
      _/_/_/_/_/ LOOK FOR IT IN A NEIGHBORHOOD NEAR YOU_/_/_/_/_/    g s
==================================================================
= The content of this message, with the exception of any external 
= quotations under fair use, are released to the Public Domain    
==================================================================
Received on Tue Sep 30 23:17:06 2003

This archive was generated by hypermail 2.1.8 : Tue Sep 30 2003 - 23:17:09 CDT