Author: Andrew Dados
Date: 18:28:28 02/28/00
Go up one level in this thread
On February 28, 2000 at 20:28:56, Bruce Moreland wrote: >On February 28, 2000 at 17:04:13, William Bryant wrote: > >>I am curious, >>do you hash a different constant for each of the 16 possible ep squares, or >>simply a single constant if ep is possible. >> >>I have sixteen different values that are XOR'ed into the hash signature >>depending on which square is the ep square. >> >>It is intersting that Bruce made a comment about this a while back. He noted >>that the same opening position reached by a different order of moves will >>produce a different hash signature doing ep squares in this way. Therefore it >>does create a degree of inefficiency because (except for the ep move) the rest >>of the position may have already been evaluated and in the hash table. >> >>William >>wbryant@ix.netcom.com > >If you hash in en-passant square mindlessly you get a surprising amount of hash >inefficiency. > >1. e4 e5 2. c4 and 1. c4 e5 2. e4 produce the same position, and an en-passant >capture is not possible in either. Yet I bet that some people hash in the >d-file code in the first case and the e-file code in the second case. > >I found that it made more sense to check for an adjacent pawn. In that case the >en-passant capture is at least pseudo-legal. > >bruce There are few possibilities when *not hashing* en-passant can screw up. Let's analyze them all: 1. First we got into a position when ep was possible and later we got into 'same' position, but no e.p. possible (or other e.p.): a) We failed high on ep move, (or score was exact). In that case ep move will be in HT as 'best move'. While it's common to validate moves coming from hash table, this should not be the problem to catch. I simply need to search on, disregarding hashtable info. If other then ep move is best, this HT entry can be used now... b) We failed low while ep was possible, we'll still fail low without it, so we can use hash information here safely. 2. First we got into a position with no ep possibility. Now we have 'same' position, but with ep: a) If we failed high on that position we still can use that info, including best move. If HT score can't get cutoff, we'll still need to search all moves, now including ep moves anyway... a1) if hashtable score is 'exact' we're in trouble - we can't use it now without searching ep move(s). And only them. We've got a good bound from HT here, anyway. b) if we previously failed low, now, similar as in (a1), we only need to search ep moves if hashtable bounds are useful for cutoff. So only 2.a1) and 2.b) situations need to be handled by lazy programmer who does not adjust HT signature to reflect e.p possibility... One other solution: When e.p. is possible we can suppress hashtable lookup/storing... This in hope we'll get all HT hits on very next ply... Anyway, it looks like one can write 'proper' hashing routine without adjusting hash signature for e.p. at all. A matter of taste, of course (and minimizing nodecounts :) -Andrew-
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.