From: Alan Dechert <alan_at_openvotingconsortium_dot_org>

Date: Sat May 01 2004 - 13:47:06 CDT

Date: Sat May 01 2004 - 13:47:06 CDT

David,

*> On Apr 30, 2004, at 9:23 PM, Alan Dechert wrote:
*

*> > I'm not sure of these calculations and I'm not sure compression could
*

*> > not be
*

*> > used effectively.
*

*>
*

*> Compression as such is really just not workable. It just can't work to
*

*> have the barcode be of indeterminate size (and possibly longer than
*

*> usable). ....
*

*>
*

Maybe the problem is semantical.

*> However, rather than -compression- we can use more optimal
*

*> encodings of contests, thereby obtaining theoretical best sizes. It is
*

*> not difficult to create an optimal encoding for each contest type.
*

*>
*

Perhaps "optimal encoding" is what I am thinking of as a form of data

compression.

Here's something I pointed out when we had this discussion last AUG:

The possibilities for the first 7 bits are:

1000000

0100000

0010000

0001000

0000100

0000010

0000001

0000000

Currently, we indicate each bit one-by-one so we use 7 bits. However, there

are only 8 possible patterns for these 7 bits. These 8 patterns could be

represented by 3 bits if you had a way to map these patterns to 000 001 010

011 100 101 110 111.

I figured that using this "compression" method, the digits or symbols needed

on the barcode could be about half. Instead of 3 inches, the barcode could

have been 1.5 inches. After testing with the scanner, we decided it wasn't

necessary so I dropped the idea.

Arthur mentioned a scheme he had devised that would be even more efficient

at "compressing" the data.

Alan D.

==================================================================

= The content of this message, with the exception of any external

= quotations under fair use, are released to the Public Domain

==================================================================

Received on Mon May 31 23:17:01 2004

*
This archive was generated by hypermail 2.1.8
: Mon May 31 2004 - 23:18:15 CDT
*