It would also probably be useful to get some kind of informal map of different voting systems plotted on a spectrum of relative characteristics. I think a triangular spectrum of stable vs. simple vs. consensual could be a good place to start.

]]>But really, the best methods will just ignore the information that goes beyond ranking, or if they do use it, it is as a last resort.

I'm not overly concerned with bullet voting, as those voters are choosing to not use all the power granted to them. I wouldn't characterize it as a vulnerability, any more than people choosing not to vote, or choosing to equally rank candidates (if that is allowed).

As for what I think is most sellable to the public: probably ranked not cardinal ballots, simply because RCV is a thing. I think you could sell a Condorcet method while just calling it RCV. Bottom-2-runoff is good in that it is the smallest change to RCV. A simple version of minimax is good because it can be based on a pairwise matrix alone, which makes it most easily precinct summable.

Recursive IRV is.... well I'm kinda obsessing over it at the moment. But I won't say more at the moment until I understand it better.

]]>I did some hover effects on the matrix some years back, but it would be especially cool if you could have the two things side by side, and when you hover over a pair of candidates on the matrix, or the connector line between the candidates on the "mesh" display, it would highlight relevant things in both graphics at once.

(this is for voting for restaurants, as we did at a previous job I had where they ordered lunch for us every day and we'd always waste time arguing about which one to get each day)

alt text

I'm convinced that allowing people to visualize this stuff **quickly** makes it less scary to them. Nobody wants to sort through tons of data, a picture can make a big difference.

A pairwise matrix without colors and hover effects / animation is extremely hard to make heads or tails of.... but all the better if you can show a simpler-seeming graphic that has each candidate on it only once.

]]>I think electors tend to be mostly faithful to the interests of their states (at least as far as can be determined by the gerrymandered districts), especially I think since they have the pressure of public scrutiny to more-or-less rubber stamp the results as they come in, and hopefully they also have some humility in their own decision-making powers and confidence in the larger process. I do think it gets problematic because entrusting electors to distribute their votes according to a less black-and-white indication of state interests does give them significantly more political power and responsibility that they will also need to be held accountable for. Generally I don't mind the concept of electors/representative arbiters as long as the incentives are sorted out. The way I see it all we can hope for is a system that consistently gives results that are good enough for national success, and if such a system does the job that'd be just fine with me.

I also think it’s a good sign that we’re at the point of discussing potential issues with real large-scale implementation.

]]>However I think it's still useful to study such methods, as you never know how voters' moods will change, and maybe a simpler method like one I listed can act as a stepping stone towards a more complex one.

Yeah, I'm ok with that. There's certainly nothing wrong with studying them, and it seems to be a good method if complexity isn't an issue.

And I totally understand why they published it the way they did. If all they did was provide a reason to switch to a better existing method, well.... that would be a pretty lame academic paper.

I just felt that their lead up was very good, they called out two real problems with IRV, then suggest that there are only two options:

we must consider which of the following approaches is preferable:

(1) deciding almost every election in a simple way—just elect the Condorcet winner—and rarely applying a more complicated backup plan, perhaps more complicated than IRV, or

(2) deciding many elections with a fairly complicated iterative elimination of candidates and transferring of votes, which may cause controversy when failing to elect a candidate who beats every other?

Without mentioning a third:

3) deciding almost every election in a simple way—just elect the Condorcet winner—and rarely applying the tried and tested IRV method

I should add, there are two kinds of complexity. IRV is complex in that it goes through this messy process which seems to delay election results (presumably because of its lack of precinct summability? I mean, computers are fast so that alone shouldn't be an issue. )

But IRV is easy enough to explain, and it has already been put into legislation, so all you have to do is copy and paste from, say, San Francisco's law.

The other kind of complexity is what we have with Stable Voting. It is recursive and seems pretty hard to explain, especially in a way that can be put into legal code.

]]>This is a little nitpicky, but the notation

P(f(k, e) = c)

implies that k is random (because if k is fixed, then this probability would have to be either 0 or 1), but this is not stated.

Assuming that there are finite possible seeds and that each seed is equally likely to be chosen, we could write:

P(f(k, e) = c) = sum over s in S (I_c(f(s, e)))/|S|,

where S is the set of seeds, I_c(f(s, e)) = 1 if f(s, e) = c and I_c(f(s, e)) = 0 otherwise.

For many methods, |S| might need to be chosen in a way that depends on some limited information about the election, in particular the number of candidates (since for there to be an even 3-way tiebreaker, |S| needs to be divisible by 3 and so on). Methods that are "routinely" non-deterministic (such as random ballot) might also require the number of votes to select |S|.

]]>https://codepen.io/karmatics/pen/eYJxXge

Mine looked like this (when there is only one of a particular vote combination, there is no number and colon on the left needed):

134: a[5] b[4] c[2] d[1] e[0] f[0]

64: a[5] b[4] c[3] d[1] e[0] f[0]

94: a[3] b[5] c[4] d[1] e[0] f[0]

70: a[2] b[2] c[5] d[2] e[0] f[0]

63: a[0] b[0] c[0] d[3] e[4] f[5]

55: a[0] b[0] c[1] d[3] e[5] f[4]

55: a[0] b[1] c[2] d[3] e[5] f[3]

48: a[0] b[0] c[1] d[3] e[5] f[5]

30: a[1] b[0] c[0] d[3] e[3] f[5]

30: a[0] b[1] c[2] d[5] e[5] f[4]

You can see I have a parser and all that.

This one worked with the format of data from an actual election in Maine, which is an ugly and bulky csv format:

https://codepen.io/karmatics/pen/eYJxoMa

I was doing this when I was hoping that Codepen embedding would be added to this forum, not sure if that is in the works. But I think if it was, having a standard format would gain a lot of traction here.

]]>