Author: Uri Blass
Date: 02:45:19 10/20/04
Go up one level in this thread
On October 20, 2004 at 05:27:21, Richard Pijl wrote: >On October 20, 2004 at 05:23:00, Uri Blass wrote: > >>On October 20, 2004 at 04:57:22, Richard Pijl wrote: >> >>> >>>>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. >>> >>>This is different from just a separate qsearch hashtable. In fact, I do have two >>>hashtables now, one depth preferred, and one replace always and did find an >>>improvement by doing it this way. The depth preferred table is supposed to store >>>the 'expensive' nodes, where the replace always table should store the 'local' >>>nodes. Catching the 'local' transpositions is mainly used for shallow searches, >>>but limiting it to only qsearch seems to be counter-productive. >>>Richard. >> >>You do not need 2 tables for that purpose and you can use one table with more >>than one move for every hash entry. >> >>Uri > >I guess you mean more than one position? >That is what I'm doing, I've got just one chunk of memory that I'm addressing, >and every hash entry consists of two positions. But logically you can look at it >as two tables. >Richard. Yes You are right. I still did not implement it and I first need to fix other things one of my problems is that I do not store partial depth in the hash tables and I plan to replace my depth from having 2 variables to 1 variable so things are going to be easier. Today movei is one of the most stupid program in using hash tables. I do not hash in the qsearch and I also do not store information in the hash unless the score is above beta. There are clearly more important things to do then trying to hash the qsearch nodes. Uri
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.