-----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. 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. 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. 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. 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. - - Don -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG99rfDsOllbwnSikRAhpcAJ4kiSdmrKY7t7y4/QduYRXOAHP0/gCfXe4s RSFl84SyG7206q0Tu+JXdmU= =+gki -----END PGP SIGNATURE----- _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
