Computer Chess Club Archives


Search

Terms

Messages

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

Author: Robert Hyatt

Date: 19:10:56 02/28/00

Go up one level in this thread


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.
>>>
>>>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-


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.



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.