[EM] In defense of the Electoral College (was Re: Making a Bad Thing Worse)

Dave Ketchum davek at clarityconnect.com
Tue Nov 11 13:22:37 PST 2008


On Tue, 11 Nov 2008 20:16:55 +0100 Kristofer Munsterhjelm wrote:
>>> A possible tiebreaker for same names would be to prepend (or append) 
>>> the state of origin to each candidate name. In case two have the same 
>>> name in the same state, the state decides who gets to be "number one" 
>>> and "number two". These corner cases would be extremely unlikely, but 
>>> it doesn't hurt to specify them.
>>
>>
>> My point was that this is a problem affecting ANY election method, 
>> thus not needing special attention for Condorcet.
> 
Again, the method does not matter.  If the name Bush turns up from two 
different sources it is essential to determine whether it is:
      One candidate, for whom the votes must be summed or
      Two candidates, competing separately, that must somehow be identified 
  as such.
> 
> That's true, but for methods that only need an array (like Plurality, or 
> a weighted positional method where the method was agreed upon in 
> advance), this happens more or less informally. States don't pass around 
> explicit arrays with candidates in specific orders when tallying 
> Presidential votes, they just say "Bush got this many, Gore got that many".
> 
> The other side of the coin is that non-summable methods would be in real 
> trouble. Any compact solution defaulting to a method that isn't summable 
> would somehow have to set up an infrastructure (either in counting or in 
> communication), wherein a central unit coordinates.
> 
>>> The results should be the same with a plain merge as with a single 
>>> count, since a Condorcet matrix entry cm[a][b] just lists how many 
>>> voters ranked A > B. Consider voters that couldn't vote on a given 
>>> candidate as if they had no effective preference regarding that 
>>> candidate. Then, by including the results of some other Condorcet 
>>> matrix, if A and B wasn't on that other matrix, cm[a][b] won't change.
>>>
>> Not being sure what you mean by "simple merge", I will repeat my demand.
>>
>> For example, assume A is a write-in which CANNOT be planned on but 
>> must be adjusted for when counting the ballots.  The national NxN 
>> array must include A reflecting proper counts for all votes in the 
>> US.  True that such an A is  unlikely, but to be expected more if you 
>> assume it will never happen.
> 
> 
> A simple merge sorts the arrays by name (and tie-breaking info, like 
> name of state of origin). Then it merges the data, summing cells if the 
> candidate in question exists in both matrices, otherwise inserting the 
> relevant rows and colums in the right place so that the result (merged) 
> matrix is still sorted.
> 
> For instance, consider these matrices:
> 
> x A  B
> A -- 30
> B 35 --
> 
> and
> 
> x A  C
> A -- 100
> C 25 --

Assuming that this represents 100 votes for A then 100 A>C is represented. 
  If B was also in the matrix there would be 100 A>B.  This last 100 fails 
to show up below:

> 
> The result is
> 
> x A  B  C
> A -- 30 100
> B 35 -- 0
> C 25 0  --
> 
> and the expanded matrix stays sorted. Individual write-ins can be 
> handled by considering each voter's ballot as a Condorcet matrix, then 
> merging that in as above. In extreme case (each voter names a different 
> write-in), that would make the matrix expand by a lot, but if that's a 
> concern, sparse representation formats can be used.
-- 
  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