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).
even if it were as primitive as having a function “simulate(X)”
I’m toying with each Bot having a “simulated” flag, and at the beginning of each game, create a real and a simulated version of each Bot, and let both Bots look at what the simulated Bots are doing. Haven’t thought properly about it yet, but the rest of the project is coming along much faster than I’d anticipated so I’ll have time to dig into this problem soon.
EDIT: I think I can do better. If bots have a single source code in some language L, and inferior interpreters I-weak, and the game has superior interpreter I-strong, then I-weak(L) can approximate I-strong(L). Especially neat is that I-weak’s inferiority can come from inability to recurse; it could bottom out and choose arbitrary values to feed back in—or it could come from instruction limitations; no more than 10,000 or so.
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).
I’m toying with each Bot having a “simulated” flag, and at the beginning of each game, create a real and a simulated version of each Bot, and let both Bots look at what the simulated Bots are doing. Haven’t thought properly about it yet, but the rest of the project is coming along much faster than I’d anticipated so I’ll have time to dig into this problem soon.
EDIT: I think I can do better. If bots have a single source code in some language L, and inferior interpreters I-weak, and the game has superior interpreter I-strong, then I-weak(L) can approximate I-strong(L). Especially neat is that I-weak’s inferiority can come from inability to recurse; it could bottom out and choose arbitrary values to feed back in—or it could come from instruction limitations; no more than 10,000 or so.