Author: Dieter Buerssner
Date: 08:59:31 09/02/01
Go up one level in this thread
On September 02, 2001 at 04:25:48, Georg v. Zimmermann wrote: >- If the hash type is a lower bound , this means that the true value can be as >low or lower. So you should check for a fail low, not "].Score >= beta". That >is >wrong. Same for the upper bound. If I am not totally mistaken, the normal terminology is, that a lower bound is a score is not lower than this. It comes from a fail high in a previous search. So, it looks right to me in the original search. >- You are not adjusting the bounds, why ? That helps a lot. I have thought about this for many times, and actually I am adjusting alpha. I see however the following problem. When you have window dependent pruning, it can happen, that a first fail high gives a different score, when researching with a different window. This adds more inconsistencies. The search may not be able to reproduce the score with the different window setting, which leaves the question whom to trust, the hash table or the actual search with the current window. Also, when adjusting alpha to a lower bound value, this value is actually outside of the window. So, say the value was actually exact, one ends up without a PV. Also, it is not really clear, what sort of node this is. It was a lower bound earlier, now it an upper bound that is inside of the original search window, but outside of the window with the adjusted bounds. >> Which of them do I store in Hash Table? Which comparisons do I make when >>retrieving from table? The stored hash signature should be the same, as in the current position, also the side to move (which can be handled in different ways, by hashing it, by using 2 tables and possibly more). Ep target and castling rights should be the same (and may most convieniently be used in the actual hash signature). But one could argue, that it works also without the same ep target and castling rights in practice. To have some safeguard against collisions, you can check the hash move for legality in the current position. >> Presently I store "depth" and retrieve as shown below, but retrieved values are >>clearly wrong. >> >> // Retrieving data from Hash >> if ((HashTable->HashEntry[ChessPosition->HaskKey].nChecksum == >>ChessPosition->LockKey) && \ What are nChecksum and LockKey? Regards, Dieter
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.