[EM] percentage support continued

Paul Kislanko kislanko at airmail.net
Wed May 4 16:14:19 PDT 2005

``` Dave Ketchum wrote
> For the whole district (state in this case) we need an array
> with a column
> and row for each candidate.
>
> The ballots do not come in in this format.  Makes sense, at
> or near the
> polling place, to convert them to array format, for the array
> format is
> efficient for data transmission, and such arrays can be
> summed, element by
> element.
I haven't personally worked on election counting software, but I would be
extremely surprised if the people who do don't convert ballots to an array
format for transmission - otherwise it would be pretty much impossible to
provide the coverage the TV provide.
>
> Makes sense to do the summing in whatever sub-districts make
> sense, such
> as county.  These arrays may be interesting enough to publish
> and to analyze.
I think they ARE published and analyzed already. When you see the
county-by-county breakdowns in the newspaper presented in an n-county-row by
m-candidate-column format you are looking at an array. You don't think some
reporter re-typed all those numbers, do you?

>
> While not part of the Condorcet data for declaring winners, a
> row could be
> added to such arrays, to record each ballot's first choice.
> While some
> may complain, correctly, that getting the most first choice
> determine winning, it does show voter desires, while the
> final numbers in
> the arrays are the result of adjusting to account for
> conflicting stated
> desires.
>       AND, these voter desires CAN be stated as percentages.
If the "Condorcet data" means the pairwise matrix, what you'd want is more
likely an extra column to contain the first place votes.

Actually, you can analyze an election by using two arrays generated from the
same set of ranked ballots.

Let B be the "ballot matrix" with n candidates defining the rows and n
columns defining the number of voters who voted for candidate i for place j.
In this array every column can be an expressed as a percentage: x of T
voters had the candidate ranked 1st, y of T voters had a different candidate
rated first, and so on. x2 of T voters had the candidate the candidate rated
2nd, y2 of T voters had a different candidate rated 2nd, and so on...

Then you have the nXn pairwise matrix, which just shows the "how many
preffered candidate A over candidate B" data.

Any combination of the two is some variation on Borda, but views of the
ballot set provide useful information, and if anything it is easier to
calculate the candidate vs rank array than the pairwise matrix. Producing
the "percentage matrix" is just an O(n) addition to any program that can
produce a pairwise matrix, since it only takes about 3 lines of code to do
that.

> Write-ins require thought:
>       Likely thought would be to combine them as if one extra
> candidate.
>       Then, assuming normal use of this feature, the count would show
> nothing more needed doing.

This is the right approach. All "write-ins" = "write-in" is the candidate.
Despite the best efforts of the AI folks, the fact will remain at least for
our lifetimes that any "write in" vote will require manual review.

And it just struck me that there's no really easy way to automate the entry
of a ranked ballot where every rank could potentially be a write-in...

Hmmmm....

```