Author: martin fierz
Date: 01:44:44 10/20/04
Go up one level in this thread
On October 20, 2004 at 03:39:31, Gian-Carlo Pascutto wrote: >On October 20, 2004 at 02:27:19, martin fierz wrote: > >>so i want to store the move itself in the hashtable instead of the moveindex >>now, as probably everybody is doing. > >Naah. 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? >>the question i have is this: should i stick >>with two separate tables for QS and main search? or should i just use a single >>big table (seems more sensible to me). or should i do no hashing at all in QS? >>any opinions on this? > >One table vs two tables seems like a clear case for one table to me (what would >two tables gain, except less efficiency?). well, there are people doing two hashtables anyway, one for shallow and one for deep nodes. qs/main search fulfils that type of requirement too. not that i'm convinced of using 2 tables at all, just asking around for opinions. >To hash or not to hash, that must be *tested*. sure. do you really think i'm not going to test it?? of course i will test it - i just hope to get some feedback on this issue. if everybody here says "i'm doing X and it is much better than all alternatives" i will implement X and not play around with it too much. if everybody offers a different way of doing things then i'll play around with it some more... cheers martin
This page took 0.01 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.