Another Iterated Prisoner's Dilemma Tournament?

Evolution:

Each agent is represented by a function; for concreteness let it be a real function of some relevant subset of previous turns. If the return value on a given turn is positive, the agent cooperates, else it defects. The function is represented as a tree; each node is a function with a fixed number of parameters (zero parameters = constant). Mutations are realised as cutting random branches and replacing them by constants. Sexual reproduction would take two functions and swap some branches. Population dynamics would be basically the same as in the last tournament.

Variable match length:

I would simply make up a number N which I will not tell anyone before the game starts. Then, each match would be preceded by generating a random real number x between 0 and 1, and the match length would be set to exp(xN) rounded up to integers, or something similar.

I was prepared to accept code, pseudocode, and English descriptions, and then translate them into coffeescript myself.

I did it last time and it was pain in the arse. It's fun to code one PD agent, not so much when they are forty and you must follow descriptions which you are not sure that you understand correctly.

I have written an interpreter which evaluates functions written in a lisp-like prefix notation, which was originally intended to be used in a program evolving automatic traders using genetic algorithms and real stock exchange data - the traders were represented as functions. Changing it to be applicable to PD simulations would be quite easy. Mutations are already coded too.

The idea of simulating opponents was mentioned in the discussion and relates to all sorts of LW decision theory idiosyncrasies. I think it's worth doing, even if it were as primitive as having a function "simulate(X)" which would return the result of the opponent's decision function where all instances of "simulate" are replaced by X (which is either C or D).

Your post on IPD mechanics is very interesting! I'm going to implement TFT-Dn, TFT-DnC, and CRD alongside TFT, Cooperate, Defect, and GrimTrigger as basic types of bots. Not sure if I'll include them in the tournaments, though.

No; but that particular concept is trivially easy to include (and will be included unless I come up with something better). It's literally a change from YourBot.new(gamelength) toYourBot.new(gamelength, m). I'm thinking about other ways to allow interesting evolution. The current best idea is something like providing an Evolution object that has all sorts of interesting numbers that change in all sorts of interesting ways with each population step. (The biggest bother I had with the m concept was that you can't have monotonically increasing numbers to plug into bots that want to do interesting things over time - for example, "play tit for tat until population step 1000, and now that all the silly strategies are dead and it's a pool of tit-for-tatters, play CliqueBot")

I think DefectBot, RandomBot and at least TFT-0D should be included by default. The last tournament was pretty much a battle of TFT-nD with varying n; I wonder if a new tournament would only result in an equivalent battle of Afterparty (TFT-DnC) strategies or whether we would actually see more successful CliqueBots and maybe completely new approaches. The tools are there.

mainly because defectors often can't be punished.

If each round came with a "situation variable" per bot that determined how 'unfair' the situation was - i.e, high variable means you can get away with defecting - and it wasn't somehow just noise, that might come closer to reality. Outside of the scope of my project, though.

LOL @ dating being analogous to a fixed length iterated Prisoner's Dilemma. [insert tired cliché joke about nerds here]