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