[EM] percentage support continued

Dave Ketchum davek at clarityconnect.com
Wed May 4 18:41:40 PDT 2005

On Wed, 4 May 2005 18:14:19 -0500 Paul Kislanko wrote:

>  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 
> 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. 

The arrays I write of cannot be converted back to the ballots they 
describe, but they are EXACTLY what is needed to determine the Condorcet 
winner - and also a compact statement that people, and programs, can learn 
to interpret from.

>>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?

Since you are likely thinking of a report for an election using Plurality 
method, not the same array, but agreed the newspaper needs and 
wants something useful they can pass on to their readers.


NOTE my adding an extra row to the array for first choice - your last 
response implied you missed this.

>>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 
>>votes does not 
>>determine winning, it does show voter desires, while the 
>>final numbers in 
>>the arrays are the result of adjusting to account for 
>>conflicting stated 
>>      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...

If you want to continue this array, let's make it a separate discussion - 
not clear to me how we get to useful results.

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

For this array each candidate owns a row and a column, with each row 
counting preferences for this candidate, and each column counting 
preferences against this candidate (thus you have a count of A>B, and a 
count of B>A - I also like permitting A=B and say, when two voters vote 
A=B, let us count as if one said A>B and one said B>A).

> 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.

Not clear to me - but may not matter.

>>Write-ins require thought:
>>      Likely thought would be to combine them as if one extra 
>>      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.

Could be true for paper ballots.  For electronic voting, the voting 
machine can include a keyboard - still have to argue over spellings, but 
getting possible.

Apparently some states permit a sort of write-in where the candidate does 
declare candidacy, though without the formality of nomination.  Here even 
scribbling on a paper ballot could be matchable against a list of declared 

> 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... 

Certainly doable for the nXn matrix; I remain unclear about the other.

> Hmmmm....

  davek at clarityconnect.com    people.clarityconnect.com/webpages3/davek
  Dave Ketchum   108 Halstead Ave, Owego, NY  13827-1708   607-687-5026
            Do to no one what you would not want done to you.
                  If you want peace, work for justice.

More information about the Election-Methods mailing list