On 9/24/07, Don Dailey <[EMAIL PROTECTED]> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I had a very kiss algorithm previously. It was very close to > > time_to_use = 0.1 * (time_left - 60) > > My impression is that you over-engineer (or over-think) everything. You > try to improve on something before you've implemented something that is > simple and you know works reasonably well.
I certainly won't deny over-thinking/over-engineering a lot of stuff :) Always do the simple thing first and prove to yourself that it is broken > before you try to fix it. Then you have a base-line you can test > against. > > Why time_left - 60? If you have less than 1 minute left your program > is going to have negative time. You are starting your program out > right away with a 1 minute time-handicap. There is no reason to do > this. I had a lower bound on the time per move to avoid negative time issues. If you are afraid you will lose on time, don't worry about that too much > unless you see it happening. In theory it will NEVER happen with this > kind of function but in practice network delays or other timing > ambiguities can have an influence. In my opinion, if you NEVER lose on time your time-control algorithm is > too conservative. To make the best use of your time you want to end > every game with NO time left - although that is not possible in practice > when using sudden death time-controls that CGOS uses. There is no > virtue in never losing on time if you are playing with a big time > handicap. Actually, that's exactly why I started experimenting with alternative timing strategies. My old method, while KISS, was too conservative. It never lost on time. It would go into the 60 second buffer here and there, but never went over. Most games ended with a significant amount of time remaining. If you want a different curve, don't use a multiplier, use a different > math operator or function. You may want some function that takes into > consideration the move number. The principle here would be to > consider that the number of moves remaining is not likely to be as high > at move 50 as it is at move 1. What I do can probably be improved but > it gets away from KISS. Actually, my logic was based on more complex analysis with the move number, or more precisely, the number of moves assumed to be left in the game. Rather than 1/10 as in my simple example, it really was (3/assumed_moves_remaining), where assumed_moves_remaining = max(10, (assumed_game_length-moves_played)/2), and assumed_game_length = boardsize*boardsize*3/2. In practice, the time usage seemed relatively close to that used by fixed percentage of time remaining. Using a simplified approach of 0.1*(time_left - 1*my_moves_left)+1 as the time control, then the results seem reasonable. In 120 move 9x9 game (assumed), 60 are for one color. That gives 25 seconds for move 1, 9.3seconds for move 20, 4.2 seconds for move 40, and 2.1 seconds for move 60 (about where most CGOS games end). It may be a bit aggressive, but should be fairly reasonable. Also, by aggressively using the spare time, I'm helping stress my time management. It happens that the time management works well for housebot-xxx-ucb, but isn't working so well with housebot-xxx-shuff because it takes too long to aggregate results and eats too much of the time padding. (Note that I'm not using 1 second per move, but a significantly smaller value). I also think 1/10 of the remaining time per move is too aggressive, but > you can figure this out with testing. > > It will never be perfect because you can't know in advance how long a > game will last. If you know your opponent will resign when he is > losing for instance, you would be far more aggressive about your time > control because you only have to allocate enough time to achieve a won > game, not to finish the game and you don't care much about losing on > time in a lost position. > > Probably, an ideal algorithm will consider: > > 1. The move number. > 2. The opponent > 3. The score. > 4. The difficulty of the current position. > > You can gain some time playing easy moves quickly, but you can shoot > yourself in the foot if you don't get this right! Don't even try to > get fancy until your program is so good that you must seek competitive > refinements. Now that I've done a few methods that haven't worked, it's almost a matter of principle that I get it right. It's a nice distraction before going back to testing AMAF implementation performance. I really didn't mean to start a large discussion on time control. I wonder if others find this dialog useful.
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
