Computer Chess Club Archives




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

Author: Robert Hyatt

Date: 14:57:51 02/29/00

Go up one level in this thread

On February 28, 2000 at 22:48:25, Andrew Dados wrote:

>On February 28, 2000 at 22:10:56, Robert Hyatt wrote:
>>On February 28, 2000 at 21:28:28, Andrew Dados wrote:
>>>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 :)
>>I don't understand the 'minimizing node count' issue.  At position P you
>>just double-pushed a pawn and it can be captured on e4.  You hash in a
>>random number.  One move later you remove it since EP is not possible.
>>In fact, I hash in the EP random number at move X, and remove it the very
>>next ply since after making a move the EP is no longer legal.  This means
>>that the EP doesn't effect hashing at all, except for the position where
>>the EP is legal, which is where it should be different anyway.
>And your approach looks best to me here.
>But suppose you need to research 'the same' position but with different e.p.
>rights. Now in case en passant was/is not the best move, and you have best
>move/score in hashtable already (but for different e.p. rights), then you may
>lose some nodes if hash entries for child nodes are overwritten. No idea how it
>can matter if at all...

Remember that a position with EP possible hashes to a different signature than
a position without EP possible.  So there is no 'overwriting' just because the
position (less the EP status) is the same.  Because the hash signatures are
significantly different.

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.