Author: Uri Blass
Date: 15:56:26 07/30/04
Go up one level in this thread
On July 30, 2004 at 18:43:29, Uri Blass wrote: >On July 30, 2004 at 18:10:39, Sune Fischer wrote: > >>On July 30, 2004 at 10:24:23, Robert Hyatt wrote: >> >>>On July 29, 2004 at 19:32:37, Sune Fischer wrote: >>> >>>>On July 29, 2004 at 19:06:40, Uri Blass wrote: >>>> >>>>>On July 29, 2004 at 18:56:12, Sune Fischer wrote: >>>>> >>>>>>On July 28, 2004 at 17:39:14, Robert Hyatt wrote: >>>>>> >>>>>>>I should add that I fudge near time controls anyway. IE when I get close, I >>>>>>>won't try to burn off my saved time. I just let it carry over to the next T/C >>>>>>>to help there. IE there is no sense in burning 30 minutes on move 40... >>>>>> >>>>>>I don't have that fudge. >>>>>> >>>>>>If that fudge was needed I'd say something was wrong with the time manager, why >>>>>>else would one want to save up that much time in the first place? >>>>>> >>>>>>-S. >>>>> >>>>>correct pondering and easy moves. >>>> >>>>All this is scaled with the available time in my engine, easy moves takes a >>>>certain percentage of normal moves, and with a lot of time left pondering will >>>>not be a full hit only sort of a half hit. I'd need to keep searching even on a >>>>ponder hit. >>>> >>>>>It is also logical to save time in the first place for other reasons. >>>>> >>>>>Imagine that you have time control of 2 hours/40 moves+1 minute for the rest of >>>>>the game. >>>> >>>>Ok that makes sense actually. >>>> >>>>>Is it logical to use almost all the 2 hours for the first 40 moves and to get to >>>>>a serious time trouble or maybe it is better to save 30 minutes so you can use >>>>>them after move 40? >>>> >>>>I think Bob would have problems anyway, because he said he only looked at it >>>>when he got close. >>>> >>>>You'd need to consider this almost from the beginning of the game if you don't >>>>want to burn too much time in the opening. >>> >>>I do this from move 1. I just consider the _next_ time control as well, as I >>>really don't want a distinct "boundary" where I am searching for X seconds on >>>move N, but some small fraction of X seconds on move N+1 just past the time >>>control. That's asking for trouble... >> >>I see it a bit differently, I let the time control control the engine in the >>strict sense. >> >>It is pretty much what humans do with the standard FIDE time controls anyway. >>Very often at least one of the players will get very close to the control, so I >>think generally it is wise to get close also for the engine. >> >>But also, it's because I've given up a bit trying to outsmart those that insist >>on using silly conditions. >> >>I.e. suppose they set a time control like: 2 moves in 100 minues + 8 moves in 1 >>minute + 50 moves in 60 minutes + 17 moves in 2000 minutes + 100 moves in 1 >>minute.... >> >>Definitely I'm not very interested in attacking these sorts of complications :) >> >>-S. > >I think that in that case you should look for more than one time control and set >the minimal target time based on some time controls. > >In your example you should look at the following time controls and calculate >target time for everyone of them: >1)2 moves/100 minutes >2)10 move/101 minutes >3)60 moves/161 minutes >4)77 moves/2161 minutes >5)177 moves/2162 minutes > >The general problem is not practical and too much target time may do the program >slower because it takes time to calculate the smallest target time but >practically you do not have more than 3 different time controls so you can do >minimal value of 3 numbers and get good approximation. > >The most complex time controls that is used under arena is >x1 minutes/y1 moves+x2 minutes/y2 moves+x3 minutes/y3 moves forever > >In that case you need to find the minimal value of >x1/f(y1) >(x1+x2)/f(y1+y2) >(x1+x2+k*x3)/f(y1+y2+k*y3) when k>=1 is natural number. > >I do not divide by the number of moves because it is illogical because you do >not divide by 1000 when there are 1000 moves to the next time control and you >need some function. > >f must be a bounded function and I think that usually for practical cases >k=1 will give smaller target time than k>1 so you can ignore k>1 > >Note that movei already have some function f but it does not calculate the >minimal value of these numbers and it is one of the improvement that I plan in >time management. > >Uri I forgot that f does not get only the number of moves as a parameter but the number of moves is an important paramater. f(y,...) is basically based on some estimate for the expected number of moves to finish the game or to finish y moves (what happens earlier) and is based on some assumption about the distribution of the length of the game. The estimate is certainly not the best estimate and it is not based on research but I think that it is better than even not trying to have some estimate. 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.