Author: Dieter Buerssner
Date: 02:11:30 10/20/04
Go up one level in this thread
On October 20, 2004 at 04:44:44, martin fierz wrote: >naah? i think storing the move itself is much more sensible than the moveindex >and would have supposed everybody is doing the more sensible thing. at least >crafty does it that way. you can avoid generating all moves at all times, which >i have to do now. you can check whether the hashmove is valid or not. i can't do >all that with my stupid moveindex. it saves 2 bytes of course in the hashtable >entry size, but i don't think that is all-important. what are you doing then? It is even less than 2 bytes. For index you need one byte, for a typical move, 2 bytes is already enough. For example from (6 bit), to (6bit), promotion piece (3 bit). More fancy things in a typical integer type move, like captured piece, castling or ep flags, ... can be generated from those 15 bit (at the time, where you try to verify the move, this info will be practicaly free). With one indirection, even 11 bit (IIRC) are enough (moves like a1-b4 never happen). Storing the real move has also the (slight) advantage, that you have some information to detect hash collisions. BTW. Yace hashes in qsearch. It uses one table, with some substructure (3 entries per index, which are not treated identically. Almost always, one entry will be overwritten at store time). All tests I did seemed to indicate, that not hashing in qsearch is worse. Regards, Dieter
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.