[EM] IRV proponents figure out how to make IRV precinct-summable

[Juho Laatu]

--- On Wed, 25/3/09, Jonathan Lundell <jlundell at pobox.com> wrote:

> On Mar 25, 2009, at 12:19 AM, Juho
> Laatu wrote:
> 
> > Yes, good question. IRV votes thus don't
> > take excessive amount of space and can be
> > compressed and can be summed up (although
> > not very compactly).
> > 
> > Possible answers might include:
> > 
> > 1) To help verifying the vote counting
> > process. If the partial results are
> > counted/verified already locally it may
> > be more difficult to falsify the results.
> > With the modern personal computers it is
> > however also possible to anyone to collect
> > all the <100MB files in one's own computer
> > and verify the election if all the
> > districts publish their ballots.
> 
> It does seem that this kind of universal verification could
> be useful for any system in which counting is nontrivial.
> WRT IRV, one could at least publish the results of a local
> IRV count--the counts for each candidate at each round.
> Whether that's useful for verifying the process isn't all
> that clear to me, but it would carry a fair amount of
> information, and could be verified against a similar count
> at the central counting facility.

Yes, this already builds some
trust among the local people
when they see that the votes
are about what they wold expect
them to be. Local officials
(=representative of all interest
groups) with access to the local
ballots could also monitor the
election wide process locally
at the same time (even if the
official counting process
would be centralized).

In general I do think that much
can be achieved already with
well organized local vote
digitization (and summing)
process where all interest
groups are present. I think
this (and well working reliable
ballot format) is a much better
approach than possible recounts
and other debates after the
event. One can add the above
mentioned monitoring of
centralized counting process
(that may be needed if the
ballots are not properly
summable) to this.

> 
> > 
> > 2) To build trust on the system by
> > showing the partial results to people.
> > In this case the summed partial results
> > should be very simple so that every
> > regular voter can see that they are ok.
> > A Condorcet pairwise comparison matrix
> > might be too difficult. Sum of votes per
> > each candidate could be simple enough.
> > Also publishing the outcome of the
> > election based on the votes of one
> > district alone can help (although these
> > results would not be further used /
> > usable when summing up the results).
> > This is easy enough for all methods.
> > And the voters will see if the results
> > are credible, not e.g. opposite to what
> > everyone expected.
> 
> As you say, easy enough for all methods.
> 
> > 
> > 3) For general interest. The local
> > results in point 2 above are certainly
> > interesting. One must be capable of
> > summing up the results so that one can
> > see what happened. Also this case does
> > not set a requirement of reusing these
> > "summed up" results later in the process
> > when the election wide results are
> > counted (raw ballot data will do).
> > (Also the Condorcet pairwise matrix may
> > be very interesting material to study
> > and speculate on.)
> 
> Or even a tabulation (for ranked systems) of the count at
> each rank.
> 
> > 
> > 4) To hide the individual votes for
> > privacy and security reasons. Published
> > ranked votes open up some doors for vote
> > buying and coercion. It is quite easy to
> > generate unique votes when the number of
> > candidates increases. (Also individual
> > ballots are interesting from point 1, 2
> > and 3 point of view, but dangerous.)
> 
> This is a difficult tough problem for many "open voting"
> proposals. Ballot publication is a powerful tool for
> verification, but potentially violates secret-ballot
> principles.

Yes. I already noted the
importance of good local
procedures when digitizing the
votes. That is one key approach
to fighting this problem (and
gaining trust by other means
than public ballots or ballot
images).

> 
> A compromise approach for IRV ballots (though not, I think,
> Condorcet) would be to publish a summary of first place
> choices, determine the "hopeless" candidates (those that can
> safely be eliminated in the first round), and then purge the
> ballot file of those candidates before publishing the file.
> At least in a relatively large election, I think this would
> be an adequate measure to deal with the "fingerprinting"
> problem.

Yes but one may need to do first
a centralized analysis on which
candidates are weak enough
before daring to drop them out.

> 
> > 
> > 5) To distribute the load of vote
> > counting and to speed up the process.
> > This mostly applies to hand counting.
> > In the time of computers it may be
> > enough to just digitize the votes
> > locally (unless already digital) and
> > to verify these transformations.
> > 
> > 6) To keep possible recounts local. This
> > is also mainly related to hand counting.
> > Nowadays local re-digitization may often
> > be enough..
> 
> Or perhaps hand-verification of the digitization.

Yes, maybe part of 5.

Juho


> 
> > 
> > In summary, maybe raw digitized ballots
> > are good enough in most cases for the
> > computers, but humans may need more
> > compact information (not necessarily
> > summable) for various reasons. The
> > privacy point may set requirements on
> > what to publish and what not (some
> > countries are already now quite strict
> > on this). In IRV there may thus be a
> > need to keep the ballots hidden or to
> > break them in such a way that individual
> > ballots can not be recognized (or
> > verified to the buyer/coercer).
> > 
> 
> 
>