Re: Alternatives to a single bar code

From: Steve Chessin <steve_dot_chessin_at_sun_dot_com>
Date: Thu May 06 2004 - 18:41:41 CDT

>From Wed May 5 20:42:07 2004
>From: David Mertz <>
>Subject: Re: [voting-project] Alternatives to a single bar code
>Date: Wed, 5 May 2004 23:41:58 -0400
>On May 5, 2004, at 7:46 PM, Steve Chessin wrote:
>> See
> From a quick glance, this looks like it would fit comfortably in the
>80-bit informal limit I suggested for 1-D barcodes. For an exact
>number, please use my tool. I didn't look at the
>exact numbers of candidates and the like, but you can do that.

I didn't save the tool, and I don't have python on my system, and I'm
not interested in installing python on my system. (If you had
a web-based version of the tool, where I just had to upload a ballot
description file according to some posted specification, I might use
it then.)

>You're right that *IF* all those contests were ranked preference (i.e.
>IRV) then the bit count would be much higher. But in point of fact,
>none of them actually were, right?

That's missing my point. Look at it this way: are you designing a
system that is going to be obsolete if/when IRV snowballs into use?
You're aiming for deployment in 2006. San Francisco will be using IRV
in 2004. Santa Clara County will be using it in 2006, as will cities
in Alameda County. Other jurisdictions will follow, because there are
IRV activists throughout California (and in other states) and we have a
track record of success in getting IRV ballot measures passed. Are you
going to lock yourself out of those markets?

Also, I expect the use of IRV to spread after that, where it might even
be used statewide by the middle of the next decade. It's one thing to
require your customers to take a software upgrade (to change the bar
code from 1D to 2D, for example). It's another to require a hardware
change (to replace the 1D scanners with 2D scanners).

= 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:20 2004

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