nshepperd comments on Prisoner's Dilemma (with visible source code) Tournament - Less Wrong

47 Post author: AlexMennen 07 June 2013 08:30AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Article Navigation

Comments (232)

Comments (232)

You are viewing a single comment's thread. Show more comments above.

Comment author: AlexMennen 06 June 2013 02:13:09AM *  2 points [-]

Tentatively: I'll paste "(YourCode TheirCode)" into the interpreter with DrRacket, with #lang scheme.

Edit: Oops, that doesn't enforce the time limit. Just a sec while I figure this out.

Edit2: I tried this:

(define (kill-when-done thd) (sleep 10) (kill-thread thd) (print 'time-is-up))

(begin (define main-thread (thread (lambda () (your-code their-code)))) (kill-when-done main-thread))

but unfortunately threads are not guaranteed to start back up again as soon as sleep allows them to; it took about 18 seconds to terminate when I ran the second line with "your-code" being an infinite loop. I'll figure out how to do this properly tomorrow.

Edit3: A marvelously improper but correct way to do it:

(begin (define x (current-milliseconds)) (print (your-code their-code) (- (current-milliseconds) x))

Allow to run more than 10 seconds by looking at clock at stopping manually. Throw out result if it says it took more than 10 seconds.

Comment author: nshepperd 01 July 2013 05:54:34PM 0 points [-]

You should be able to use this which I just worked out, to run something with a timeout. Seems to be working by my testing. It might be overkill to run the whole thing in a subthread but it makes certain that nothing interferes with the use of send and receive here. You would normally use it with a lambda taking no arguments, for example (using my ueval)

(timeout-exec 10 (lambda () ((ueval x) y)) 'timeout)

which is what I've been using to test candidates against each other locally.

Comment author: BloodyShrimp 01 July 2013 06:20:30PM 0 points [-]

He said he didn't want to use sleep, since the argument is only a lower bound on the amount of time it takes.

Comment author: nshepperd 01 July 2013 07:15:21PM 0 points [-]

Ah, right, I see it now. I guess you can check the current-milliseconds after the fact, and force the default value in that case. But looks like this is going to be a problem if I try to safely simulate other agents... Actually, I suppose it's possible for the target thread to similarly not get returned to for a long time, causing any watchdog to overestimate the time it used. current-process-milliseconds might help with that, but I'm not sure if it can deal with nested threads usefully.

Powered by Reddit Powered by Reddit