Author: Robert Hyatt
Date: 12:50:41 04/19/04
Go up one level in this thread
On April 19, 2004 at 13:11:59, Andrew Wagner wrote: >Some have suggested this could possibly be a problem with how I store and >retrieve the bounds in my hash table, so let me explain what I do and see if the >logic is right. Much of it comes from Bruce Moreland's web site. > >My Search function calls a function called ProbeHash(). Probehash looks in the >Transposition table to see if the position has an entry stored there already. If >so, and the leaf distance of the hash entry is >= the current leaf distance, it >looks at the score and at what type of entry it is. If it's a beta entry (stored >when the move fails high), and the score is >=beta, Probehash returns beta. if >it's an alpha entry (stored after a fail high), and the score is <=alpha, alpha >is returned. If it's an exact score (the first time it was searched, the score >was between alpha and beta), the score itself is returned. If none of this is >true, it passes back a best move as a parameter. Once we arrive back at >Search(), if any of the above three cases with scores (alpha, beta, or the hash >entry score) were returned, Search immediately returns that score. Otherwise, it >continues on. > >I hope this makes sense. Does this sound correct to the rest of you? Dan, is >this similar to the logic of how you do it? Thanks! Andrew It doesn't sound right. First, terminology: LOWER is a table bound that says the stored score is a _LOWER_ bound on the value of a search from this position. The real score may be much higher than this. You store such an entry when you search some move and it fails high. You know that the score is at _least_ as good as this bound and it might be even higher. UPPER is a table bound that says the stored score is an _UPPER_ bound on the value of a search from this position. The real score may be much lower than this. You store such an entry when you search every move at a ply and _every_ one fails low leaving you with an unchanged alpha value when that search ends. Now. You do a search at at a new position you do a table probe and get a hit. First test is on "draft" as you mentioned to prove that the search this table hit represents is deep enough to satisfy the requirements of the current search depth. If you get "LOWER" then you compare the value to your current beta value and if the table value is >= the beta value, you return either the table value or beta, depending on whether you do fail-soft or not. If you get UPPER, then you compare the value to your current alpha value, and if the table value is <= the alpha value, you return either the table value or alpha, again depending on whether you do fail-soft or not. It sounded to me like you were comparing the wrong bounds... IE what you want to prove is that the search windows do not overlap. If the lower bound (from table) is > current beta value, you stop searching and "fail high here". If the upper bound (from table) is < current alpha value, you stop searching and fail low.
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.