Author: Stuart Cracraft
Date: 20:53:13 07/25/04
Go up one level in this thread
>>
>>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?
>
>>
>>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
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.