Author: rasjid chan
Date: 11:51:51 12/14/04
Go up one level in this thread
On December 14, 2004 at 13:00:12, Robert Hyatt wrote: >On December 14, 2004 at 05:46:29, rasjid chan wrote: > >>I hope somebody could comment on these : >> >> >>1) Intrinsic Search Inconsistency from Hashing - >>This may result solely from the fact that we may use hash information from a >>higher depth search which may not yet be available in an earlier search of a >>similar node. > >That is one reason. There are other kinds of problems, such as missing draws or >finding draws that are not there because the game depends on move history, but >hash entries do not have that information. > > >> >>2)In the case of implementing hashing double bounds, we may find an UB < LB. >>Say when we search a node, probehash already has a LB x_lb and >>we search with (a, b) where a > x_lb. >>The node fails low (fail soft) giving x_ub < a; with search inconsistency >>we may have x_ub < x_lb; ie an upper bound < lower bound for the same search >>depth. How can we resolve this conflict. >> >>Thanks >>Rasjid, snailchess. > > >null-move causes a problem. If the above has that kind of UB < LB and both UB >and LB have the same _draft_ then there is a problem and it should not happen. >If the UB and LB are for the same position with different drafts, then it can >happen easily. Thanks for the reply. I have not yet implemented double bounds, only revising and trying to improve on my failsoft with some complications as my TT hashes all QS nodes as well. I expected problems from my current understanding. About "then there is a problem and it should not happen" - Say w/o null-move, I can understand UB < Lb with different drafts, but was thinking it should also happen with equal drafts. Search inconsistency means different searches for the same draft at different time of similar nodes may result in differing scores that may not finally respect UB > LB. If UB == LB we conclude an exact score. UB > LB is Ok meaning we have not searched with the (a, b) covering the best score. Some reasons may be differing move extention/reduction, QS not consistently generating same class of moves (eg conditionally generating non-capture check moves), and may be many other reasons. I expect anything may happen. Or is the problem from hashing QS nodes. Thanks Rasjid
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.