Author: Robert Hyatt
Date: 08:12:48 07/26/04
Go up one level in this thread
On July 26, 2004 at 06:50:04, Uri Blass wrote: >On July 25, 2004 at 22:01:31, Robert Hyatt wrote: > >>On July 25, 2004 at 21:16:11, Uri Blass wrote: >> >>>I still do not know the reason for the bug in the time management against >>>isichess when movei used about half of it's time for move 61 (time control was 2 >>>hours/60 moves+ 30 minutes/rest of the game) >>> >>>I suspect that a possible reason for bugs in my time management may be that >>>movei simply did not update the remaining moves immediatly before it started to >>>ponder and the result is that it assumes wrong number of moves to the time >>>control and wrong time when it starts to ponder(I know that it is assuming wrong >>>time when it starts to ponder but usually it is not a big problem because the >>>target time is nearly the same and it is changed as soon as movei get the time >>>command from winboard). >> >>First rule: Write a log file. And in that log file, write _everything_ that >>might be of interest. Time limit. Absolute time limit. Etc... >> >>Then you won't be guessing the next time :) > >I have a logfile but I am afraid that I did not write there everything that may >be of interest in the game against isichess. > >In any case I think to change the global varaibles that I have for time >management and to use static local varaibles. > >After all checking time is not something that I do very often so all the >information about it should be in a specific time.cpp file that I will add when >that file will include reading the level command and having a function that >calculate the number of moves to the next time control based on the ply of the >game. > >> >> >>> >>>I am not sure if the problem was assuming wrong number of moves and movei is >>>supposed to update the remaining number of moves after every make move but I >>>think that it may be better simply to get rid of global varaibles like >>>num_moves(number of moves to the next time control, num_moves_1(number of moves >>>to the first time control),num_moves_2 number of moves to the second time >>>control and. >>>have some function with static local varaibles that movei is going to call when >>>it needs the information. >>> >>>Note that I do not plan to get rid of the compliacated formula that I use to >>>decide about time management but I plan to have function to calculate relevant >>>data instead of updating it in many places when I may forget to update it. >>> >>>I basically try to calculate number of expected moves to finish the game or the >>>next time control and use this information to decide about target time and I >>>also use the time of the last iteration to decide if to do another iteration(I >>>usually try to finish iteration in most cases with the idea that after finishing >>>an iteration there is a smaller chance to change my mind when the main exception >>>are cases when the program pondered enough time). >> >>Bad idea. Start the next iteration even if you don't think you will have time >>to finish it. You might fail low. Wouldn't that be nice to know? :) > >It is at least not clear if it is a bad idea and at least I believe that Amir is >using that idea. >In most cases I am not going to fail low and I am going to save time for later >moves. > >The question is how much time do you need to detect fail low in the next >iteration. >If you can do it fast enough then it is clear that it is better to start the >next iteration only to see if you can detect fail low in a short time but I have >no statistics about it and unfortunately I did not tell movei to print fail low >information(it prints only fail high) so I have no impression about how much >time it takes. Fail lows are much easier to search than normal positions. Because you only have to search one move at depth=2 to refute or cause the ply=1 move to fail low. > >The question is the following question: >Suppose that you used X nodes for the last iteration and you have fail low in >the next iteration. > >What is the probability that you detect fail low after less than >(1+epsilon)X nodes. > High enough that I take the gamble. :) >If the probability is high enough for epsilon that is small enough then I agree >that it is better to start the next iteration only to see if you do not fail low >in a short time. > >Uri
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.