Re: Alternatives to a single bar code

From: Arthur Keller <arthur_at_kellers_dot_org>
Date: Wed May 05 2004 - 13:23:53 CDT

At 10:42 AM -0700 5/5/04, Alan Dechert wrote:
>> San Francisco is doing its first STV based election. If it catches on we
>> will see a significant increase in the number of bits required to
>> represent a ballot.
>One county. There are 2,219 counties--not many of which do things like they
>do in San Francisco.

The University of California will build a single series of reference
systems and the system needs to handle the needs of the City and
County of San Francisco, California.

> > There have been times when ballots here in California have had on the
>> order of 40 to 50 races and questions. If even a small number of those
>> start using ranked counting methods the bit count is going to get rather
>> large.
>Please provide one specific example.

Yes/no ballots do not need rankings. Multiple choices do.
Generally, when there are lots of races and questions in a ballot,
most of them are yes/no (plus no choice made) questions, not multiple
choice races.

> > And a message digest, needed for digital signatures, is going to consume
> > at least another 16 to 32 bits.
>> To me the 2D stuff is a no brainer - it gets nearly two orders of
>> magnitude more bits at no real increase in software cost ....
>Do we have GPL 2-d software?

We'll build it if we need it and it doesn't already exist.

> > .... and only a tiny increment (an increment that may fade
>> away over time) in hardware cost.
>Maybe. However, so far, this project has zero experience with 2-D. What
>other problems happen with 2-D?

There are a lot of other things we have zero experience in, like
developing open-source software actually used in elections. That's
not stopping us.

Best regards,

Arthur M. Keller, Ph.D., 3881 Corina Way, Palo Alto, CA  94303-4507
tel +1(650)424-0202, fax +1(650)424-0424
= 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:16 2004

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