Computer Chess Club Archives




Subject: Some thoughts about *not hashing* ep at all....

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.
>If you hash in en-passant square mindlessly you get a surprising amount of hash
>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.

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,
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 :)

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.