Author: scott farrell
Date: 07:27:49 09/09/02
Go up one level in this thread
On September 08, 2002 at 08:45:12, Robert Hyatt wrote: >On September 07, 2002 at 23:44:37, scott farrell wrote: > >>On September 07, 2002 at 22:51:46, Robert Hyatt wrote: >> >>>On September 07, 2002 at 02:48:10, scott farrell wrote: >>> >>>>On September 06, 2002 at 21:38:23, Robert Hyatt wrote: >>>>> >>>>>Exactly how long does it take you to find the mate if _you_ play the >>>>>rook move yourself? I mean you play the move and let your program search >>>>>the resulting position here... >>>>> >>>>>Then we can figure out if your extensions are working by seeing how >>>>>deep you have to go to find that mate from the white side after black >>>>>blows it... >>>> >>>>The results of the rook search is below. >>>> >>>>I think I found it - my extensions when there is a nullthreat (ie. when the >>>>nullmove returns <= -INFINITY) seemed to cause this search to go the entire >>>>brute force distance of 12 plies to see the mate in 6. I am caching the >>>>nullthreat in the hashtable as well. >>> >>> >>>Here is a big question. How are you storing "depth" in the hash table? >>> >>>IE you aren't first adjusting for extensions and then storing that??? If >>>so that's a bug... >>> >> >>I am storing with depth as realdepth+extensions. I am using fractional depths, >>and store the depth including the fractional part. >> >>I think that is correct > > >I am not sure what you mean. But the answer is to look at your search code, >and pick a position and ply where you are going to probe the hash table when >you enter search. remember that number. Now assume you don't get a hit, so >do a normal search, and look at the two ways to get out of search: (1) you >get a fail high; (2) you don't. Make _sure_ that at each of those two >places, you store the _same_ depth you used when you probed the table at the >start of this search. If not, you have a problem... Robert Thanks again for that. It took me a while to understand, and implement it, and I found that whilst it is slower :) it doesnt overlook as many deep combinations. For any one else reading this, I think the 3 things have to match (which is what Robert said): - original probe depth - fail high stored depth - PV node (exact score) stored depth Thanks again Scott
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.