Echoing stonemetal, I would recommend seeing if you can refactor so that you can keep your pure function as-is, and then lift it into some monad that takes care of the logging. The Writer monad can be a good way to do this elegantly.
Yeah, I kind of suspected that this was going to involve a monad :-) And the Writer monad looks like the right one for the job.
But doesn't using that involve making the rest of the code (at least from the function that needs to log out to the top level) return monads, rather than returning whatever they were returning before?
So, it'd require making any code that calls the function doing the logging do one of two things:
1. Explicitly end the scope of implicitly logging things by calling runWriter, and getting a pair of (result, log) out.
2. Continue working in the implicit log monad, which would mostly involve extracting the result of the log function with `do x <- theLoggingThing`, but you can still mix in pure statments with `do let y = 5` or other function calls, and then end the do block with `return val`, where val was what you were going to return before.
I actually fixed the number of rounds on purpose--I figure the Nash equilibrium in the classical iterated PD isn't very relevant in this wildly different version of the game, and I want to see what kinds of strategies emerge with fixed-size rounds.
I didn't explicitly forbid collusion, since it's tough to prevent it in practice; I would appreciate it if teams simply submitted one bot or several bots with different strategies.
A perfect simulation is recursive so you need to add a resource limit. In which case a bot can either lie by detecting it's being simulated or just waste time and give out zero information.
When you call the time function, it will cut off the simulation once that 1/100th of a second limit is reached, no matter what happens inside the simulation. So even if your opponent simulates you or performs some expensive computation or even goes into an infinite loop, time will terminate in the allotted number of seconds plus the overhead. If that happens, though, it will return Nothing, so you won't have gained any information about what your opponent will do.
I mean that it doesn't seem a safe upper bound - `time` will return, but there are situations where to get a useful result, you need to increase the limit; and it's easy to get in those situations even when neither bot is running lots of repeated simulations.
This class of difficulty can't be completely eliminated, but it seems that being able to run bots for a long time relative to the overhead of `time` would reduce it.
Ah, I see what you mean now. This was deliberate--I want simulation time to be a precious resource that bots have to spend wisely. You can burn 4 seconds on one simulation that is more likely to give you valuable information, but then it's the only one you're going to get. Or you can do lots of small simulations that are less likely to return an answer. I agree that it's not very safe, which is somewhat unfortunate, but also serves to discourage bots that use precise timing as part of a strategy. Also, since timing out results in a defection rather than in some additional penalty, the risk isn't too large.
Yep, you're exactly right--I didn't actually add up the payoffs when I wrote that. You could potentially do better against tit-for-tat variants that have a certain chance of forgiving after a defection, but not against the naive, deterministic TitForTat.
