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

[Kristofer Munsterhjelm]

Dave Ketchum wrote:
> 
> On Mar 18, 2009, at 6:26 AM, Kristofer Munsterhjelm wrote:

>> It fails to pick the winner IRV would, but it picks the winner the 
>> "contingent vote" summability hack picks. The contingent vote is like 
>> this: first do a plurality count. The two candidates that have the 
>> greatest count go to the second round, where the one that's ranked 
>> above the other more often wins. The second round is thus a pairwise 
>> comparison, but it's not Condorcet, since it doesn't check all 
>> pairwise comparisons.
> 
> But I do not see summable here, for that would mean NOT going back to 
> the precincts for the second round.

As stated, it's not summable. But note that the second round, which is 
determined by the Plurality count, consists of a pairwise comparison. 
Thus, one can make the method summable by simply storing the information 
required to simulate any one-on-one runoff -- in other words, by having 
a Condorcet matrix. Since Condorcet is not mutually exclusive with 
summability, we know Condorcet matrices can be summed - so that part is 
summable. We also know that Plurality counts are summable - if A gets X 
votes in district 1 and Y votes in district 2, A got X+Y votes in these 
districts combined.

> Again, the election method better get decided on before the election, so 
> that the voters can be told the rules and thus be able to express their 
> thoughts to whatever extent they choose within what those rules support:
>      Condorcet:  A=B is fine for about equals; A>B or A<B ranking for 
> different liking, but amount of difference is neither needed nor 
> expressible.
>      IRV:  like above, except A=B not permitted, for counting would not 
> know what to do when A=B must be deciphered as top ranks.
>      score:  ratings must be decided - for A>B>C, obvious to rate A high 
> and C low, but where to place B to get maximum or minimum difference 
> between A and B or between B and C is difficult.

I'm not sure about IRV - has anyone devised an STV variant that handles 
equal rank? If not, then you're right - again, I'm not sure.

 From what I've seen of voting equipment, most limitations seem to be in 
the name of expediency. For instance, SF's RCV three-rank method keeps 
voters from ranking more than three candidates - probably to accomodate 
existing equipment.

What limitations may exist (such as your IRV example) may be handled by 
having a voting machine that permits all ranking types (full, truncated, 
equal rank), then having parameters that limit according to what kind of 
voting system is being used in the back end (e.g no equal rank).

>> My impression was that it was a hack - a way of getting a "summable" 
>> method that can be done using IRV voting machines and that's also at 
>> least slightly IRV-ish.
> 
> Sounds like it was neither summable nor truly IRV.

It is in theory possible to make it summable - see above. The method 
they did use seems not to be, though - as far as I could see, they 
checked, for all possible virtual runoffs (set by enforcing A and B as 
winners in the first round), whether A or B won. Such a binary check is 
summable only if the results are the same in both districts - but when 
they're different, one runs into trouble. Consider this, for instance:

District 1      X>Y: 1000, Y>X:  990    X beats Y
District 2      X>Y:    1, Y>X:    2    Y beats X
-------------------------------------------------
Summed result                           X beats Y

but also

District 1      X>Y: 1000, Y>X:  990    X beats Y
District 2      X>Y: 1000, Y>X: 2000    Y beats X
-------------------------------------------------
Summed result                           Y beats X

In both instances, X beats Y in the first district, and Y beats X in the 
second district, but the summed result is different for the two cases. 
Thus I think that they would have to store the entire Condorcet matrix 
(numbers of voters, not just who won) in order to be summable. If they 
did, then they're summable, but if they didn't, they aren't.

(This contradicts what I said earlier, where I claimed they were 
summable because they stored the entire CM. A rereading seems to say 
they are only storing who won the virtual runoff, but again, I could be 
wrong.)

It is, as you say, most definitely not IRV.

>> For individual ballots, rated ballots probably confer the greatest 
>> freedom. One can simulate a ranked ballot (A: 9, B: 8, C: 7) with or 
>> without ties, and approval style (A: 10, B: 10, C: 0) or Plurality 
>> style as well.
> 
> Disagreed as to freedom - rating does permit more detail - but then 
> demands that the voter decide how to express it.

I mean freedom as a data format. A rated vote data format can emulate a 
ranked vote format, as well as an approval-style data format.

>> That is, even though the voters may supply ranked or Approval type 
>> ballots (depending on the system in question), all of those could be 
>> stored as rated ballots, which means that in the event of having to 
>> change the voting method, the format doesn't change.
> 
> If the voter thinks and votes Approval, the counter cannot know how the 
> voter would have expressed Condorcet or score voting.

That is correct. One may "downconvert" but not "upconvert".

There is one exception: ranked ballot to Approval-style. The ranked 
ballot contains no information about where to put the cutoff. One could 
also generalize this exception to rated-to-ranked, saying that A: 4.99 
B: 4.98 should be A = B, but A: 49, B: 48 should be A > B. If this 
problem is significant, it would destroy the freedom argument above.

>> That's for individual ballots. But if the method is summable, one may 
>> go further and ask, what kind of summable data format would provide 
>> the most information? What kind would let one run as many different 
>> voting methods as possible without having to alter the format of 
>> what's being communicated from precincts and summed centrally? One 
>> candidate is the Condorcet matrix. Another is the weighted positional 
>> system matrix; or one may have both, to use methods like "first 
>> preference Copeland".
> 
> You seem to be thinking of our debates in EM or Rangevoting.  For an 
> actual election I claim above that the method BETTER get decided before 
> the election, and the data format and counting operations BETTER fit 
> that method.

Having a common format would let states tell manufacturers to make 
machines able to read or write to that format before they're completely 
sure as to which method using that format is to be used. For instance, 
say a state decides to use Condorcet. It's not sure as to what kind yet, 
though, but now it can order voting machines that add to Condorcet 
matrices. Some time later, but before the election, they pick (say) 
Schulze. The time of the election comes and they find the winner based 
on the Condorcet matrix data, the actual Condorcet counting part of the 
machines having been thoroughly tested.

Is that unrealistic?

> Again, the method better get decided before the election.  That two 
> methods use the same matrix does not excuse allowing for method debates 
> after the election among the various candidates claiming to have won.

The method used should be the method that counts, yes; arguing over 
other methods would not affect the outcome, except inasfar as they may 
point to problems with the method itself. In that respect, it's both a 
benefit and a disadvantage: "problems with the method" might be defined 
by the people as something like "vulnerable to vote splitting" (that's 
the benefit), but might also be defined by those in power as something 
like "too competitive" (that's the disadvantage).

>> (By the way, your From address was somewhat strange, purporting to be 
>> from my own ISP, so I used an older one - I hope it's the right one.)
> 
> Do not understand these words, but what came as cc was correct.

Simply put, the From: of your previous mail (and of this one, too) was 
"mail.clarityconnect.com at broadpark.no". Broadpark.no is where my own 
mail account resides.