Closed rdebath closed 10 years ago
A too high cycle limit makes it too easy for triplocks to win a battle, since their only problem is the time limit once they've locked the enemy.
Oops, sorry didn't reply; as long as it's "part of" the competition I don't see any problem, but one of your commit messages say it was a workaround to long run times for a full tournament.
On a related note; would you have an interest in a quick C implementation? It runs the current set of 37000 matches in about 2 seconds (on 4 cores -- I've been playing with openmp) without full logs, though as it completely expands the BF it's currently got a problem with NestDarwin.bf
Are you talking about a BF Joust interpreter? Just asking because the tournament is no real BF Joust hill, it's a modified variant.
No, just something I threw together based on your specification, not a ''standard'' joust runner..
https://gist.github.com/rdebath/965b15025725de9552b3
It's really rather slow as a BF interpreter, but it's written in C so has a huge speed advantage over python.
Like I said though, no scoring or logging as yet, just the match results.
The bot you have called 'CantTouchThis.bf' seems to be being underrated.
For example: BurlyBalder.bf vs CantTouchThis.bf, tape 20, cycles 71196, Winner: CantTouchThis.bf
Whereas if it's terminated at 10000 cycles it's a draw. But, even 100000 cycles isn't enough.
CantTouchThis.bf vs TruthBot.bf, tape 30, cycles 118531, Winner: CantTouchThis.bf
Though 200000 cycles seems to be enough, there's no significant difference between that and 10000000 cycles.