[EM] percentage support continued

[Dave Ketchum]

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


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


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


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

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