Honestly, I feel like parsing Scheme is still maybe a bit too hard—especially since we have things like multithreading (ugh) available. Maybe a subset of Scheme would have been better? Oh well. Fortunately we have people like So8ers making things easier!
Honestly, I feel like parsing Scheme is still maybe a bit too hard—especially since we have things like multithreading (ugh) available. Maybe a subset of Scheme would have been better? Oh well. Fortunately we have people like So8ers making things easier!
Fortunately that aspect of parsing (detecting the use of disallowed features) is the easiest to manage. Choose a subset yourself, announce here what you consider acceptable and declare that any use of anything not in that subset will be treated as a defection.
Yes, I was thinking of that; the problem is I’m doing this quite late, and am not even currently certain just what I’ll count as a defection, if I can even get this to work...
(Worse yet, I’m finding that my current program may have to rely on features I want to disallow! Although quite possibly in a way that won’t get them detected as disallowed...)
Agreed that even Scheme is a bit much for static analysis. We could ask AlexMennen to disallow multithreading and timing. Would there be objections to that?
Just curious: AlexMennen how many submissions have you received? Do any use multithreading or timing libraries?
I’d tentatively object. The 10-second timeout rule becomes too much of a problem if your program can’t guard against it, and changing the rules so that failure to play a real move in time = defect would also make static analysis a major pain.
Yes, I was thinking of that; the problem is I’m doing this quite late, and am not even currently certain just what I’ll count as a defection, if I can even get this to work...
The obvious option is to start by counting everything as a defection and use whatever time you have remaining (that you are willing to spend) adding new things that your code is smart enough to verify as conditional-cooperation. The smarter your code is the more cooperative it can be!
(Worse yet, I’m finding that my current program may have to rely on features I want to disallow! Although quite possibly in a way that won’t get them detected as disallowed...)
There is no strong reason the “I have to count this as defection list” you use must be the same as what you actually use in your own code (unless you think your out-of-game signalling is particularly powerful). (Assuming vaguely sane but bounded competitors) you want your code to be both as smart as possible (allowing more potential mutual cooperation opportunities) and as simple as possible (allowing agents as dumb as possible to see that they can cooperate with you). Ideally your agent would be far, far simpler to understand than what it is able to cooperate with but if you can’t manage that it isn’t a strict deal breaker.
There is no strong reason the “I have to count this as defection list” you use must be the same as what you actually use in your own code
Certainly true—if it made it so that my program wouldn’t cooperate with itself, that would be a problem, but here the “forbidden” stuff is hidden away an area my program would never actually analyze.
The problem is just that, if I need to use this, that suggests so will other people; and that means I’m probably going to be defecting in a lot of cases where I shouldn’t.
(Assuming vaguely sane but bounded competitors) you want your code to be both as smart as possible (allowing more potential mutual cooperation opportunities) and as simple as possible (allowing agents as dumb as possible to see that they can cooperate with you). Ideally your agent would be far, far simpler to understand than what it is able to cooperate with but if you can’t manage that it isn’t a strict deal breaker.
Argh, I didn’t even think about the “it should be simple to be visibly cooperating” bit. Trying to do static analysis on Scheme (with its conds and cases and quasiquotes) is enough to make my program complicated. Maybe I should just submit a MimicBot instead.
Btw, just in case anyone was thinking of doing such a thing after the declarations so far: If you do any redefining of syntax, I’m defecting on you.
Argh, I didn’t even think about the “it should be simple to be visibly cooperating” bit. Trying to do static analysis on Scheme (with its conds and cases and quasiquotes) is enough to make my program complicated. Maybe I should just submit a MimicBot instead.
Does MimicBot run the opponent and then return the same result? If so then I suggest a timeout/defect feature. Any bot that fails against itself has problems!
Are there going to be CooperateBots in the competition? If that is a possibility then consider a simple tweak “If my opponent does not make use of its opponent variable then defect else Mimic”. (Failing against unobfuscated CooperateBot is at least as embarrassing as failing against self.)
Btw, just in case anyone was thinking of doing such a thing after the declarations so far: If you do any redefining of syntax, I’m defecting on you.
Anyone who tries that must and doesn’t expect defection must seriously hold the opposition in contempt!
Does MimicBot run the opponent and then return the same result? If so then I suggest a timeout/defect feature. Any bot that fails against itself has problems!
By MimicBot I mean the strategy given in this comment. It’s not great, but it’s better than not ever finishing.
Are there going to be CooperateBots in the competition? If that is a possibility then consider a simple tweak “If my opponent does not make use of its opponent variable then defect else Mimic”. (Failing against unobfuscated CooperateBot is at least as embarrassing as failing against self.)
Hm, that’s not a bad idea. My current program is essentially trying to measure to what extent their output depends on mine, but if I can’t finish that in time, that’s a simple tweak that can be added...
Agreed—need something with easy parsing for this.
Honestly, I feel like parsing Scheme is still maybe a bit too hard—especially since we have things like multithreading (ugh) available. Maybe a subset of Scheme would have been better? Oh well. Fortunately we have people like So8ers making things easier!
Fortunately that aspect of parsing (detecting the use of disallowed features) is the easiest to manage. Choose a subset yourself, announce here what you consider acceptable and declare that any use of anything not in that subset will be treated as a defection.
Yes, I was thinking of that; the problem is I’m doing this quite late, and am not even currently certain just what I’ll count as a defection, if I can even get this to work...
(Worse yet, I’m finding that my current program may have to rely on features I want to disallow! Although quite possibly in a way that won’t get them detected as disallowed...)
Agreed that even Scheme is a bit much for static analysis. We could ask AlexMennen to disallow multithreading and timing. Would there be objections to that?
Just curious: AlexMennen how many submissions have you received? Do any use multithreading or timing libraries?
I’d tentatively object. The 10-second timeout rule becomes too much of a problem if your program can’t guard against it, and changing the rules so that failure to play a real move in time = defect would also make static analysis a major pain.
The obvious option is to start by counting everything as a defection and use whatever time you have remaining (that you are willing to spend) adding new things that your code is smart enough to verify as conditional-cooperation. The smarter your code is the more cooperative it can be!
There is no strong reason the “I have to count this as defection list” you use must be the same as what you actually use in your own code (unless you think your out-of-game signalling is particularly powerful). (Assuming vaguely sane but bounded competitors) you want your code to be both as smart as possible (allowing more potential mutual cooperation opportunities) and as simple as possible (allowing agents as dumb as possible to see that they can cooperate with you). Ideally your agent would be far, far simpler to understand than what it is able to cooperate with but if you can’t manage that it isn’t a strict deal breaker.
Certainly true—if it made it so that my program wouldn’t cooperate with itself, that would be a problem, but here the “forbidden” stuff is hidden away an area my program would never actually analyze.
The problem is just that, if I need to use this, that suggests so will other people; and that means I’m probably going to be defecting in a lot of cases where I shouldn’t.
Argh, I didn’t even think about the “it should be simple to be visibly cooperating” bit. Trying to do static analysis on Scheme (with its conds and cases and quasiquotes) is enough to make my program complicated. Maybe I should just submit a MimicBot instead.
Btw, just in case anyone was thinking of doing such a thing after the declarations so far: If you do any redefining of syntax, I’m defecting on you.
Does MimicBot run the opponent and then return the same result? If so then I suggest a timeout/defect feature. Any bot that fails against itself has problems!
Are there going to be CooperateBots in the competition? If that is a possibility then consider a simple tweak “If my opponent does not make use of its opponent variable then defect else Mimic”. (Failing against unobfuscated CooperateBot is at least as embarrassing as failing against self.)
Anyone who tries that must and doesn’t expect defection must seriously hold the opposition in contempt!
By MimicBot I mean the strategy given in this comment. It’s not great, but it’s better than not ever finishing.
Hm, that’s not a bad idea. My current program is essentially trying to measure to what extent their output depends on mine, but if I can’t finish that in time, that’s a simple tweak that can be added...