Talk:Summability criterion: Difference between revisions

: The summability criterion has a very particular definition: it means that the storage space required grows only logarithmically in the number of voters and polynomially in the number of candidates. The format you propose is linear (i.e. not logarithmic) in the number of voters and thus isn't counted as summable of any order.

: Practically speaking, there's no problem using computers to store the raw ballots, even for very large elections. Suppose that we have a ranked worldwide election with 15 candidates, and turnout is 100%. That's 8.1 billion ballots. We can store a [[Space of possible elections#Full rankings, equality allowed|rank order of 15 candidates with equal-rank allowed in 48 bits]]. Total storage required is thus 48.6 GB, which fits comfortably on modern memory cards.

: But suppose you did the same count with FPTP. Now you can write the results down on paper (15 candidates, a max of ten digits each) and it's pretty easy to see who's in the lead. With a Condorcet matrix, it's not quite as easy to interpret the matrix, but it should fit on paper and with some calculation you should be able to see who the CW is.

: So in a way, summability is more about "human-summable" than it is about managable period. A summable method keeps things at a human scale and it makes recounts easier to verify through their summaries. Usually the results can be interpreted more easily as well, e.g. IRV may have Sankey graphs, but they don't tell you who would have won if matters changed slightly. One caveat about this: higher order summable methods would lose these benefits quickly. (E.g. a method with an n^4 summary array would be hard to interpret and deal with.) [[User:Kristomun|Kristomun]] ([[User talk:Kristomun|talk]]) 18:52, 21 December 2023 (UTC)