For anyone who needs "ballot-counting code," I suggest you try my Graphical Voter Interface (GVI), which you can find at http://ElectionMethods.org/GVI.htm . GVI is professional-quality software that goes way beyond a command-line interface. It is close to usable in a real public election. Screenshots are available at the website. Here is a synopsis of GVI:

GVI, The Graphical Voter Interface, is a GUI (Graphical User Interface) for voting, suitable for use in private or public elections. Although it could be adapted for online voting, it is currently intended only for conventional "precinct" voting. For security reasons, GVI does not require that the voter have access to a keyboard. It can handle write-ins and multi-language elections, and it can automate voting along party lines. GVI can be used for Condorcet Voting and Instant Runoff Voting, which allow voters to rank the candidates in order of preference. It can also be used for Approval Voting, which allows voters to select more than one candidate.

--Russ


Craig Carey research-at-ijs.co.nz |EMlist| wrote:

The public fills in preference lists. What your Python code did was designed
to do was to trash the public into doing something it never did, sought, or
has a reason for: create a pretext and deceptive cover story for you. What
do you want: to believe the lie which is that Condorcet's original thought
was correct and that there seem to be Comdorcet cycles (those difficult
to resolve things).

The reason the input stage code was missing, is to help you get attached.
E.g. some concrete to keep you at the bottom of the water off the edge of
the wharf, and eventually you would be cataloguing the fish and boots.



At 2005-02-01 04:03 +0000 Tuesday, MIKE OSSIPOFF wrote:

Craig Carey said:

What the blazes ?: OSSIPOFF's Python code couldn't even accept ballot paper
counts as input. That is what I saw at the Piaelli website.

I reply:

Very good point. I agree that it didn't make sense for the Python listing to not have code for receiving and counting rankings. The Python code that I'd written, and Russ had it in its final debugged version, received and counted the raw input to get the pairwise vote totals.

I wanted the program to be usable by anyone who wanted to copy it, and I wanted it to be complete and self-contained. So I included code to receive the rankings from a keyboard, and, from those rankings, to determine the pairwise vote totals, and use those to determine the winner.

Russ passionately insisted no one would want to enter rankings from the kekyboard. One could ask, then, if he thought that people would rather determine the pairwise vote totals without any assistance from a computer program.

Sure, for a user who writes programs, that user can write his own ranking-receiving and counting program. But I wanted the program to be accessible to people who weren't inclined to write their own input code. No such luck. Russ left out the keyboard input and count code, leaving a program that had the pairwise vote totals as its inputs--inputs to be obtained by the user however s/he manages to.

Of course someone who wants to write their own input code could disregard the keyboard-input code.

By the way, the code to receive the rankings from a keyboard and count them to find the pairwise vote totals was considerably longer than the part that uses those pairwise vote totals for the BeatpathWinner algorithm. That's because, for practical use, it's necessary to give the user a way to correct any keyboard-input errors that s/he makes, and to indicate when s/he has completed each ranking, and when s/he has entered all the rankings. That makes the code considerably longer.

---- Election-methods mailing list - see http://electorama.com/em for list info

Reply via email to