[EM] simplcity of range v condorcet

[bql at bolson.org]

On Sat, 13 Aug 2005, Warren Smith wrote:

> I challenge people to write computer programs to perform condorcet and 
> range elections.  I have so far never encountered anybody who produced a 
> shorter program for condorcet. Not even close.

I find this an interesting point as I have implemented quite a few 
election methods in C, Java and sometimes perl. Most of them turn out to 
be 'a couple hundred lines' of Java. IRV is annoying to implement AND a 
bad method, so I've been letting it slack as I upgrade things. But, I 
always implement some Condorcet method (beatpath or CSSD) and my pet IRNR.

Anyway, these code implementations ought to be within the grasp of anyone 
who chooses to inspect the source. If this code was going to get worked 
into actual voting machines I'd expect perhaps a couple hundred people at 
most to actually bother with that. Hopefully those would be enough for 
people to trust the smart hackers that the voting machine code is good.

As for the methods themselves, easily explainable is definitely a selling 
point. The IRV crowd at the euphemistically-named 'fairvote.org' have put 
some work into this. I tried to make a friendlier "Virtual Round Robin" 
(Condorcet) slide show at
http://bolson.org/voting/VRRexplaination.pdf

The crowd on this list seems to be still buisily hunting for the Golden 
Election Method. No such consensus on the GEM having been found, the 
arguments rage on. I've been more interested lately in advocating to get 
the laws changed and get _something_ better than single vote enacted 
_soon_. So, that means simple explaination advocacy, and boilerplate law 
to hand to our state legislators.

Oh, but then I got distracted by redistricting, which is also an 
interesting problem. :-)


Brian Olson
http://bolson.org/