Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Hashing

Author: Sune Fischer

Date: 17:02:16 04/04/03

Go up one level in this thread


On April 04, 2003 at 17:10:15, Russell Reagan wrote:

>On April 04, 2003 at 16:55:02, Dieter Buerssner wrote:
>
>>Yes. For example, double a pawn for the side to move in such a way, that the
>>additional pawn has no (pseudo) legal move - it will be very easy to find many
>>such positions. Also the game theoretical result of such a position can
>>certainly change, by adding that pawn.
>>
>>Anyway, I think normal hashing works well, if done carefully (including ep and
>>castling rights). The main problem I see, is the wrong handling of reptetions
>>(when you reach the same position after different moves, it is not really the
>>same ...), and possibly some subtle points including extensions. Say you reach a
>>position after a capture, you might do a recapture extension. On another path,
>>you might not trigger that recapture extension. In general you just do not
>>search the same tree. This can yield in some search inconsistencies. I think,
>>there is no cure, that does not take away many of the nice advantages of HTs.
>
>
>Instead of fiddling around with all of the special cases of when to hash this or
>that, how well do you think a combination approach would work? Use (say) 32-bits
>for the "board arrangement" hash key, and 32-bits for a "move list" hash key,
>packed into one 64-bit hash key. Then you would only match positions that were
>setup the same on the board and also had the same (pseudo) legal moves. Does
>this do anything to solve any problems? Or does it only create new ones?

A movelist hash won't work at all.
Suppose you have two positions with identical movelists, in one position there
is e.g. a trapped knight, in the other position with the same movelist there is
no knight. Now these positions are not identical because different trees can
(and will!) unfold after this position. Different subtrees == different
positions.
In the example with the e.p. capture, if there is no capture possible the tree
is going to be identical whether you set the flag or not, thus _not_ setting the
flag is better if you want as many hash hits by transpositions as possible.
Castle flags are important, again because different subtrees will emerge.

-S.



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.