Collaborative Coding for Simulation

[Jack Waugh]

I'm still thinking about a simulator to run in a browser. As I envision it, the way it would work is that the human would enter a list of candidates, then describe an electorate consisting of various voting factions. The user would give for each faction, the faction's attitudes toward the candidates. The number of voters in each faction could be fixed, or it could be a multiplier times the setting of a slider control. So for example, shifting the slider control could reduce the number of "Republicans" and "Democrats" and increase the number of Libertarians and Greens.

The user could also choose from selections of voting systems and strategies for the simulation. Once these are chosen, every time the user moves the slider, the system would redo all the election simulations and show who wins in each combination of strategy and tallying rule. So for example, you could have IRV with naive strategy, Score with naive strategy, Score with a strategy to exaggerate support for lesser-evil candidates (without inverting ranks), Score with a bullet-voting strategy, STAR with the same selection of strategies as available for Score, and so on. Come to think of it, I could let the user specify different strategies for different factions.

So for the coding of this, I'm seeing myself as principal programmer and I want to supply the overall framework, the input mechanism, and some of the tallying and strategic pieces. But I want it to be as easy as possible for guest programmers to contribute additional tallying and strategy choices.

I think it would help me with the engineering design if I had examples of what potential guest programmers consider easy and straightforward when it comes to coding strategy modules. So I'm soliciting example draft code. It does not have to have been tested. It's OK if it has mistakes. I just want to see what you consider straightforward and to the point and direct and easiest when it comes to how these algorithms would be coded. You can make what assumptions you want about the format of the inputs and outputs to these procedures. The input expresses the valuations of the faction you are working for, toward the candidates. The candidates should probably be represented as just index numbers. The input also must provide some representation of the best prediction your faction has about the stances of the other factions. I plan to put the truth in there, but in theory, the framework could be expanded to model partial knowledge i. e. some degree of uncertainty. I leave it to you whether to include that possibility, and if so, to what degree and in what format to model the map between possible stances of the other factions and the probability that those are their stances. For example, it could just be "we think that faction evaluates the candidates with these true scores, but we are only 80% certain", whatever a statement like that might mean to you.

The output of a strategy module must denote a list of subfactions and their votes. There could be for example one subfaction consisting of the whole faction. If there are a thousand voters in the faction, the output could indicate 1000 subfactions, each consisting of a single voter. The reason for this flexibility is to allow to insert randomness within the faction. A given strategy module would usually be aimed at the voting systems with a single type of ballot, e. g. Score-type, strict ranking, or ranking permitting equal ranking (a. k. a. partial order).

I'm offering three choices for the programming language syntax: Javascript, FORTH-like, or Lisp-like. I think it likely that each of you will prefer Javascript, but I'm throwing the others out there because I think I could do them. I could be quite flexible about what semantics to attach to the syntaxes and what kinds of library functions to provide. For example, there could be a class of collections with map, filter, and reduce.

So, in summary, I am soliciting draft code for voting strategies.

@culi @rob

[Jack Waugh]

Maybe for modeling uncertainty, the presentation should be a series of "polls" that inaccurately indicate the stances of the factions in the overall electorate.

[rob]

@jack-waugh I have concerns about the concept of "factions." I believe that under a good system, factions tend to blur into one another. Instead it is just loose correlations. For instance, there might be a correlation between being pro-choice and anti-gun. But that might not be as strong a correlation if a good election system reduces the whole "tribalness" that tends to force people to be in one camp or another camp. So I hope you don't just assume factions with hard boundaries.

Yes of course I would say JavaScript. If it runs in a browser, it kind of needs to be. I'd be 1000 times more likely to contribute if I can code right in a browser, such as using Codepen. Frankly I'd advise that the whole thing be designed from the get-go to work in Codepen. (note that codepen can pull js files from elsewhere, and it can be embedded in posts)

I did some experimental work some time ago to make it so we can have stuff like this run right in people's posts (but not using Codepen). No, people wouldn't be able to post arbitrary javascript, but they could post things that had data in it that was fed to your program, and the results of that would run right in people's posts. Let me know if you want to know more.

[Jack Waugh]

@rob In regard to "factions":

First off, I should clarify that the person I mean by "user" is the one who is describing the candidate list, the electorate, etc. for a simulation. In short, defining the problem the simulator is tasked to solve. No programming skill is required of the user. I'm thinking that a guest programmer would give me their code and I would integrate it in the framework.

If the user wants to describe an electorate with a thousand voters, or ten thousand, or a hundred thousand, or a million, said user (U) is not going to want to sit there and list for each of the million voters, that voter's evaluations of the maybe 18 candidates. Instead, the user should be able to describe chunks of voters who share the same evaluations. I have been calling such chunks of like-minded voters "factions". Do you propose a different name and/or a different scheme for what options are open to the user in laying out the problem?

In regard to the Codepen tool:

What constraints does it impose that wouldn't apply to a website that I might implement?

In regard to the programming language and to an example:

You have chosen Javascript. So what I would be interested in seeing from you is an example strategy function in Javascript. Again, it doesn't have to be tested. It can be a first draft.

[rob]

@jack-waugh
I'm not sure what you are looking for regarding a "strategy function" but you can look at how I implemented strategy for a few methods in my simulator.

This video does show code, and if you want you can look at the code in the actual app (which has been improved / expanded since I made the video), here it is:
https://pianop.ly/voteSim/voteSim.html

Youtube Video

(also, I'm not sure how this is particularly relevant to the JavaScript question. I mean, any language should be able to do whatever algorithm you come up with, right? )

The way I implemented strategy is pretty simple. Basically, I assume that voters would attempt to guess who would be the front runners, and vote accordingly. So if it is approval and you know that the winner will be one of four candidates out of ten, you approve all candidates that you like equal to or better than the average score you give each of those four candidates. (a bit simplistic, but reasonable)

The trick is how to know who will be the front runners. And to do this, I just iterated, having everyone voting with the above algorithm, then narrow down the candidates. And it iterates until it stabilizes. Some voters were "more strategic" than others, which simply meant that they were able to narrow it down further. So the least strategic would vote as if all candidates were front runners, while the most strategic would narrow it down to two. My simulator showed the progress by animating the sorting of candidates, slowly enough that your eyes can sort of follow it. (it shows how strategic each voter is by the "warmth" of their color: oranger is more strategic, bluer is less strategic)

Not sure if that makes sense, but feel free to watch the video and play with the app and look at the code if you want.

I did sort of the opposite extreme of putting each voter into a faction. I just spread them over a 2d ideological spectrum with a random distribution. I don't think that is perfectly realistic, and think a little "clumping" would improve it. But I never got around to that.

One of these days I'll put some more work into the app. I'd like to do IRV but that one is tricky strategywise. I am not convinced that a good Condorcet method would have any reasonable strategy beyond ranking them in your order of preference. So I only did approval, FPTP, score and for and against, all of which have a fairly straight forward strategy if you know which of the candidates is in the running.

[Jack Waugh]

@rob, thanks for that link to the code.

I wasn't looking just for algorithms, but more particularly, to know the techniques whereby they are carried out and whereby the inputs and results are coupled from and to the rest of the program.

I see that you use imperative style and native looping constructs + setTimeout.

[rob]

@jack-waugh Yes I find imperative styles easy to follow especially by the less experienced. setTimeout() is to allow for the animations.

I'm curious what approach you are using to simulate strategy. Is it purely based on being able to guess the front runners, "hall of mirrors" style (as mine is), or something else?

[Jack Waugh]

@rob said in Collaborative Coding for Simulation:

what approach you are using to simulate strategy

I haven't implemented anything yet, but was thinking along the lines of heuristics. I would make available to the strategic code, the preferences of all the factions (a more sophisticated simulation for some purposes could blur these, but to start with, I would provide them verbatim). If the favorite candidate of the faction the code is working for at the moment is unpopular, the code would look for a lesser evil. For Score, the less popular the preferred candidate is, the greater the degree to which the support for the lesser evil would be exaggerated.

[rob]

@jack-waugh Sounds really difficult to do in a way where it is actually good strategy. For instance, how do you determine if a candidate is popular? Does it mean "likely to be elected under the current method?" Because that by its nature needs to be iteratively solved. (well, that's the only way I can think of to solve that). And then, how do you determine how good voters are at guessing how others will vote? Do they all have equal ability?

I also have trouble imagining how you decide what voters go in what faction, in anything approaching realism, unless you do something along the lines of what I did which is give each voter (and each candidate) a position in "ideological space", which I simplified into a 2-dimensional space. Note that in the latest version I also gave candidates a "universal appeal" property, so it wasn't only about proximity to the candidate in ideological space.

Finally, I don't know how to algorithmically do strategic voting under IRV or Condorcet. It seems like a voter needs to be able to guess with a great deal of precision how others will vote in order to effectively rank the candidates in anything other than your sincere preferences.

[Jack Waugh]

@rob I feel there is a certain amount of demerit in my spending more time jawboning about the simulation I have in mind than coding it. Nevertheless.

I am choosing to exclude from the scope of the simulation, any modeling of how or why the voters come to the evaluations they have of the candidates. I want to simply allow the researcher (the user) to specify those. The purpose of running the simulations is to see which combinations of strategies and voting systems do better in the sense of tipping the result the way the researcher is interested in (presumably, toward defeating the duopoly) with the least support in terms of count of voters on one side or the other with respect to whatever polarization interests the researcher. My idea is to allow the researcher to find this tipping point by titration, by adjusting a slider control back and forth and observing when the combinations of voting systems with strategies for them tip between electing the sort of candidate the researcher supports to the sort the researcher opposes. The slider position will affect the numbers of voters holding certain valuations of the candidates and nothing else. The valuations will drive the votes via the strategies. Every seriously proposed voting system has an obvious naïve strategy, and I will offer that in all cases.

For Condorcet and IRV, I don't know offhand any strategies to offer other than the naïve strategy, which is just to order the candidates according to preference. This is the strategy recommended by IRV advocates.

For Score (and STAR), the popularity of the preferred candidate is directly available in the simulation (as it would not be in real life) from the evaluations of the voters toward the candidates. A threshold could be chosen based on what the candidate scores would be in a forced "honest" Score election, based on reading the voters' minds rather than giving them freedom of choice. Maybe instead of a hard threshold, this should be a parameter to choose a logistic function through which to map the scores given to the middle candidates. I'm not sure whether that makes sense; it's just an idea. But generally, the idea is that if honest scoring would elect Nader, there is no need to settle for Gore or Bush, whichever we judge to be the lesser evil. But if Nader is polling at 1%, we might care about the Gore-Bush part of the election and would want to exaggerate support for the lesser evil.

So, my assumption is that all voters are perfectly good at guessing what the other voters want (not how they will vote), and as good as the author of the strategy routine at choosing an advantageous strategy. The reason for these assumptions is I am trying to pit the voting systems against each other, above all else. I want to find out, and show others, circumstances where one voting system "works" better than the other at overcoming the kinds of antidemocratic behaviors that FPtP exhibits. I believe that when a system has been in place for several elections, all factions will figure out how best to game it for their purposes, to the extent that is possible. My grounds for expecting this are general Darwinism plus the experience that every American knows that a naïve choice under FPtP is not always the most advantageous choice.

I haven't thought about any simulation that would address the choice that a potential candidate would make to run or not run, as a variable to be computed. But the choice not to run in FPtP is an example of how the public has come to understand strategy.

[Marylander]

@rob said in Collaborative Coding for Simulation:

Finally, I don't know how to algorithmically do strategic voting under IRV or Condorcet. It seems like a voter needs to be able to guess with a great deal of precision how others will vote in order to effectively rank the candidates in anything other than your sincere preferences.

Usually in Condorcet, strategy involves trying to force a cycle. But you will then have the task of determining whether doing this is beneficial for you.

A general case for voting strategy might be to define some sort of distance between two elections based on the number of ballots changed (but perhaps assigning different weights to each ballot-vote combination, since some voters wouldn't want to participate in a strategy as it undermines what they want, also, if your supporters aren't easily persuaded to vote strategically, they might require higher weights; the weights would represent the difficulty of convincing a voter to cast a specific vote), and then a naive approach might be to find the election with a different outcome of nearest distance to the election that is expected, then for each voter to choose from the votes that they are willing to cast whichever vote either maximizes or minimizes the distance from the expected election given their chosen vote and the nearest different outcome, depending on whether they prefer it or not.

One challenge with this idea is that strategy is local, so the distance won't be valid everywhere. Another is that it doesn't take into account uncertainty in our estimates.

I think that this is a bit of a ways off from being something you could usefully code, but I think it could develop into a useful model.

[Jack Waugh]

@marylander said in Collaborative Coding for Simulation:

find the election with a different outcome of nearest distance to the election that is expected

Your choice of concepts invites me to reexamine which ones I'm emphasizing when thinking about strategy. A way to look at is to start by asking whether the freedom of movement available to our faction allows us cast better than a naïve vote in terms of the quality of the electoral outcome as measured by our values. The expected election might be the one that would result if we voted naïvely and our opponents bullet voted. If there's an algorithm that explores all around the envelope of what we can do in search of a better outcome, assuming the opponents continue to bullet vote, that could be interesting. If no better alternative election is found within that freedom of movement, we should vote naïvely in order to avoid perturbing the secondary indications of the election. If more than one better election is found, we should try to force the best one.

[rob]

@marylander said in Collaborative Coding for Simulation:

Usually in Condorcet, strategy involves trying to force a cycle. But you will then have the task of determining whether doing this is beneficial for you.

Yeah my feeling -- and it is more of a feeling than anything I've been able to mathematically reason -- is that for a normal voter to try to do this is going to be beyond their capabilities. They might try, but they are probably equally likely to do something has a negative effect as to have a positive effect. And if it does have a positive effect, it will be an extremely subtle one.

This is nothing like how under other systems -- such as FPTP, Approval, and Score -- simply knowing who the two front runners are dramatically helps you to vote effectively. Even being able to narrow it down, say from a field of 8 to a field of 4, makes a big difference.

[Marylander]

@rob said in Collaborative Coding for Simulation:

Yeah my feeling -- and it is more of a feeling than anything I've been able to mathematically reason -- is that for a normal voter to try to do this is going to be beyond their capabilities. They might try, but they are probably equally likely to do something has a negative effect as to have a positive effect. And if it does have a positive effect, it will be an extremely subtle one.

I think there are simple cases where it might be possible for voters to use Condorcet strategy, if only because a campaign might be able to figure out some burial scenario and try to communicate to their voters "do this, just trust me." I have center-squeeze cases in mind in particular: often when the plurality winner has 1 pairwise win and 1 pairwise defeat to the (sincere) Condorcet winner, they'll win if their voters bury the sincere Condorcet winner. If the plurality winner's pairwise victory is large enough, the risk of this strategy is low. But the campaign itself would have to push this, since voters are not very good at figuring out strategy when left to their own devices.

[tec]

@jack-waugh on the original question regarding languages, I don't really know FORTH (or its variations) and I have a strong attraction to LISP. But for the simple and practical reasons that simulations have to be run on some system, having JavaScript client code is really the only way to go if you want more than a handful of users running simultaneous simulations.

[tec]

If you are looking for voting strategies and you aren't already familiar with it, you might want to look at Warren D. Smith's 2000 Range Voting paper. In it he proposes Range Voting (now more commonly referred to as Score) and compares it to about 30 other voting methods (really 14 other methods with naïve and strategic variations), The last I checked the paper can be found at Range Voting. The (c) code is also available at votetest2.c.

According to the (many) voting papers I've read over the past several years, there is a major decision that needs to be made when representing the electorate. In my opinion, the worst option is to use tournaments, which essentially ignore voters and even elections, and are about choosing a winner among a fixed set of alternatives based on a graph in which an arrow points from node A to node B if A would defeat B in a one-on-one simple majority election. The graph is just a given, and the challenge is to figure out a way to pick the winner. These papers have tended to focus on the computational difficulty of making this choice when the graph is large. The second way of representing the electorate is preference profiles, which is just a ranking of the fixed set of alternatives combined with a mulitplicity for each raking indicating how many voters would order the alternative that way. My problem with this method is that it doesn't provide any data for approval voting or score voting, or indeed any cardinal voting method.

My preferred method (which generally requires computer simulation for any realistically sized electorate) is to represent voters as points in an issue space (usually 2D or higher), and use a distance function between the voters and the alternatives (also points in the issue space) to generate ordinal or cardinal ballots.

One of the projects I'm considering is to start with something like Nicky Case's To Build A Better Ballot, and use interactive JavaScript to illustrate many of the problems with various voting systems. This is also similar to what @rob did in the underlying electorate model in his voting strategy simulation. (I do have an ulterior motive here. If the simulations start with the voters and distance functions to the alternatives, it becomes a lot easier to show exactly how an iterative voting system like SAVE would work, and how it would be significantly better than any non-iterative system. That argument is a lot easier with pictures.)

[rob]

@tec said in Collaborative Coding for Simulation:

My preferred method (which generally requires computer simulation for any realistically sized electorate) is to represent voters as points in an issue space (usually 2D or higher), and use a distance function between the voters and the alternatives (also points in the issue space) to generate ordinal or cardinal ballots.
......
This is also similar to what @rob did in the underlying electorate model in his voting strategy simulation

Yes that is exactly what I do. The thing I do that isn't realistic at all, though, is that I simply spread the voters around with a random distribution, rather than having any clustering at all. That said, most of the clustering in US politics today is, in my opinion, caused by the voting system itself. Duverger's law and such. So I erred in the opposite direction, and assumed that it was spread evenly among the electorate. The orange/gray/blue dots below represent voters in "issue space" (or "ideological space"). The crosshair simply indicates the median value of X and Y.

I use 2 dimensions rather than more because it is easier to show on screen, as well as just being the right level of complexity to illustrate concepts to people (which I prioritized a bit higher than making it fully realistic). Both candidates and voters have an X and a Y value. When talking about it, I usually consider X to mean "left vs. right", both in a geometrical sense but also political. (so I can talk about "voters on the left" indicating liberals/democrats, at least in the US politics sense)

In addition to X and Y values, voters have another property which is "how strategic they are." This is shown in the color: orange is fully strategic, blue is fully sincere. I use this in a simplified, but not totally unrealistic way: those that are the most strategic vote as if they know for sure who the two front runners are, those who are most sincere vote as if they consider every single candidate equally likely to be elected. Those in the middle will vote as if some in-between number of candidates (say, 4) will be front-runners.

Meanwhile, candidates (large colored dots with a letter on them) have a property beyond their X Y position in issue space, and that is what I call "universal appeal." This can include things like their appearance, their speaking skills and debating skills, their intelligence, and so on. Basically, those things that are deemed good regardless of what a voter's position on issues are. So candidate B above has higher universal appeal than others, while candidate E has lower universal appeal. This is shown by size. (note that the video I shared earlier did not have this as I hadn't implemented it yet)

Notice that I have also added one more thing to the simulation, which is the "Raw" scoring in the output. (at right)

This is not calculated based on any vote, but just by determining the average "voter satisfaction" at their being elected. I consider this to be an indication of what is the best winner actually is. This only works because the app has the ability to essentially read the voter's minds --- for the actual voting methods, the app can only look at their ballots.

It is expected that the raw scoring "method" will tend to give the candidate nearest the median (i.e. the crosshair) the highest score. More or less. And this assumes that all have the same universal appeal.

I haven't yet tried to do Condorcet methods, STAR or IRV, since strategy is so much more complicated for them.

(the app in its current form -- i.e. unfinished -- is at https://pianop.ly/voteSim/voteSim.html . To use it, first click "make voters", then click around to place candidates, then click "vote". You can delete candidates by clicking on them, you can adjust their universal appeal by mousing over them and using up and down arrow keys, or by using the "default UA" slider prior to placing them)

[paretoman]

Codesandbox

If you have a github repo, you can automatically deploy to CodeSandbox.io to give a sandbox for your creations.

Here's an example I'm working on: https://codesandbox.io/s/github/paretoman/votekit

Embeds

Also, we might be able to embed examples here: https://codesandbox.io/docs/embedding

But that is something that would have to be specifically set up somehow on NodeBB, and I don't really know about that. For now, a link is good.

[Jack Waugh]

@rob, does this code represent voter affinities toward candidates?

[rob]

@jack-waugh said in Collaborative Coding for Simulation:

@rob, does this code represent voter affinities toward candidates?

Are you speaking of Paretoman's code? I don't know what it represents, I ran it quickly but in the absence of a good explanation I don't know what it is supposed to be showing.

Personally I'd recommend a video demo if he cares to do one. OBS and YouTube are your friends.