This is a followup to a post I made in the open thread last week; apologies if this comes off as spammy. I will be running a program equilibrium iterated prisoner’s dilemma tournament (inspired by the one last year). There are a few key differences from last year’s tournament: First, the tournament is in Haskell rather than Scheme. Second, the penalty for bots that do not finish their computation within the pre-set time limit has been reduced. Third, bots have the ability to run/simulate each other but cannot directly view each other’s source code.
Here are the rules and a brief tutorial (which are significantly more fleshed out than they were last week). I intend to open up the tournament and announce it via a discussion post in a few days, but until then, I would love to hear your feedback and suggested changes to the rules/implementation, no matter how major or minor. When the tournament opens, LW users with 50+ karma who do not know Haskell can PM me with an algorithm/psuedocode, and I will translate it into a working bot for them.
Each bot will play one match against all other bots and against itself
This biases the tournament towards cooperation and makes it no longer a PD.
If multiple people submit identical bots, only one copy of the bot will be entered
This biases the tournament away from the defect every single round strategy.
Consider creating an elimination tournament where you run the game, eliminate the bottom half of the players, then run again, then iterate until only one player remains. If you decide to do this and are willing to go to the effort of programming my entry (since I don’t know Haskell) please enter me with a bot that always defects.
Can you explain the rationale behind the elimination setup a little more? An elimination tournament seems less fair than pure round-robin. Moreover, I ran some tests with various combinations of the example bots from the tutorial, and what generally happens is the bots with strategies along the lines of “I’ll cooperate if you do” (i.e. tit-for-tat, justiceBot, mirrorBot) rise to the top and then just cooperate with each other, resulting in a multi-way tie. If the actual pool of submissions contain enough bots with that kind of strategy, a large tie seems inevitable. This result doesn’t sound very exciting for a competition, but is there is some sense in which it is theoretically “better” than round-robin?
Edit: This outcome doesn’t always happen, but it happens most of the time.
The elimination tournament better simulates evolution and capitalism. With a round robin you can have a successful strategy of taking resources from stupid people. But in nature and the marketplace stupid people won’t consistently get resources and so a strategy of taking from them will not be a long-term effective one.
This is a followup to a post I made in the open thread last week; apologies if this comes off as spammy. I will be running a program equilibrium iterated prisoner’s dilemma tournament (inspired by the one last year). There are a few key differences from last year’s tournament: First, the tournament is in Haskell rather than Scheme. Second, the penalty for bots that do not finish their computation within the pre-set time limit has been reduced. Third, bots have the ability to run/simulate each other but cannot directly view each other’s source code.
Here are the rules and a brief tutorial (which are significantly more fleshed out than they were last week). I intend to open up the tournament and announce it via a discussion post in a few days, but until then, I would love to hear your feedback and suggested changes to the rules/implementation, no matter how major or minor. When the tournament opens, LW users with 50+ karma who do not know Haskell can PM me with an algorithm/psuedocode, and I will translate it into a working bot for them.
This biases the tournament towards cooperation and makes it no longer a PD.
This biases the tournament away from the defect every single round strategy.
Consider creating an elimination tournament where you run the game, eliminate the bottom half of the players, then run again, then iterate until only one player remains. If you decide to do this and are willing to go to the effort of programming my entry (since I don’t know Haskell) please enter me with a bot that always defects.
Thank you! These changes both make sense; I will adjust the tournament structure as you described and enter your bot when the tournament is open.
Can you explain the rationale behind the elimination setup a little more? An elimination tournament seems less fair than pure round-robin. Moreover, I ran some tests with various combinations of the example bots from the tutorial, and what generally happens is the bots with strategies along the lines of “I’ll cooperate if you do” (i.e. tit-for-tat, justiceBot, mirrorBot) rise to the top and then just cooperate with each other, resulting in a multi-way tie. If the actual pool of submissions contain enough bots with that kind of strategy, a large tie seems inevitable. This result doesn’t sound very exciting for a competition, but is there is some sense in which it is theoretically “better” than round-robin?
Edit: This outcome doesn’t always happen, but it happens most of the time.
The elimination tournament better simulates evolution and capitalism. With a round robin you can have a successful strategy of taking resources from stupid people. But in nature and the marketplace stupid people won’t consistently get resources and so a strategy of taking from them will not be a long-term effective one.
Thank you, that is an excellent explanation and you have changed my mind; I will implement an elimination tournament as you described.