Author: Volker Böhm
Date: 14:53:07 07/26/04
Go up one level in this thread
On July 25, 2004 at 23:53:13, Stuart Cracraft wrote:
>
>>>
>>>1) my time continues to overstep by up to 50% or so for a
>>>fixed time search. I expected it to overstep by very little if
>>>any after the above change.
>>
>>Be sure that you check the time-counter at each call of alpha-beta.
>
>I do but only after ensuring that the first move has been searched
>at every depth and only if the total of mainsearchnodes+quiescencenodes
>modulo 1024 is zero. If so, then I return the value of "best" which
>is the value of the first move searched. I considered and tried
>Bob Hyatt's return of a fixed number but since I set a global flag
>anyway indicating timeout, and since the search appears to be exiting
>in a timely manner every time, I'll keep this one in the bag.
>
>>
>>Don´t stop allways if running out of time.
>>I have an algorithm like:
>>
>>If more than 50% time left, search next depth.
>>If more than 20% time left, search next move on current depth.
>>Stop if more than 120% time spent.
>>Use more time if score suddenly drops.
>
>Of course, but for my purpose, maintaining a clock is not necessary
>as my research doesn't require a tournament-style program, just one
>with fixed depth and fixed time capability.
>
>>
>>-> Usually Spike does not terminate in the middle of searching a move on root.
>
>How about if the PV is being searched and you haven't finished that search
>and suddenly the allocated time is over?
That´s why I only increase search if 50% of time left and I add 20% of time when
searching a move. If last depth used for example 10 sec. I have another 10 sec +
20% = 10 sec + 4 sec = 14 sec to search the pv. Usually that´s enough and Spike
does not waste time searching a move and not finishing the search.
>
>>
>>>
>>>2) my moves obviously are frequently different now, picking the
>>>last iteration's fist move of the PV and the result on my standard
>>>test dropped from 93% to about 50%.
>>
>>See above, allways take best move from pv.
>
>I take the backed up move and stop backing it up if the time indicates
>the search is over. This was suggested by the previous writer
>
>>
>>>
>>>So my questions are on #1, where is the best place to put the
>>>immediate returns if a timeout flag is set and where is the
>>>best palce to set that flag in search and quiescence.
>>
>>never in quiescense
>>at the beginning of search
>
>Yes -- I had this.
>
>>
>>search (...)
>>{
>>TimeCount--;
>>if (TimeCount == 0)
>>{
>> if (NoTimeLeft(...)) TimeOut = true;
>> TimeCount = 10000;
>>}
>>
>>if (TimeOut) return -MaxValue;
>>...
>>}
>
>I prefer simply a measures of nodes, i.e.
>
> if (nodessearched-in-quiescence-and-main % 1024 == 0)
> check time, set timeout flag if necessary
if you only test this at search but you change
nodessearched-in-quiescence-and-main at qsearch too, can´t it happen that that
nodessearched-in-quiescence-and-main % 1024 gets zero in qsearch and not in
search?
>
>The drawback is that at my searchspeed I am doing about
>1000 gettimeofday() call's. I will experiment with higher
>values than 1024.
>
>>
>>>
>>>On #2, there must be a happy median, like "has it searched
>>>the pv from the prior iteration but changed its mind?" There
>>>must be some condition that would allow me to accept that
>>>change of mind. What is it?
>>
>>Just take the current best move from pv. Make sure that you never change pv if
>>timeout flag is set and make sure that the last pv is allways searched first.
>
>This is the wise point I was not following before reading it in this thread.
>
>Although I made the changes, my problem set solution rate is the same. But
>with time working better, I am closer to getting real research done.
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.