Author: Mridul Muralidharan
Date: 00:51:29 11/26/03
Go up one level in this thread
On November 25, 2003 at 22:19:04, macaroni wrote: >is it usefull to use hash inside the quiescent search? if so, should one use a >different table, smaller? larger? it is obvious that the quiescent hash cannot >be used for actual returns in the main search, but perhaps it can be used for >move ordering (there might be a large number of 'hits' form previous searches). >And I supose the main search hash can be used in the qsearch too if desired. Is >this all worth the memory? (and time for lookups and stores), or would I do >better to use my memory on say, another hash table insearch so I can have better >replacement schemes? >thanks Hi, In mess , I use a seperate table same size as the main transpos table in QSearch. This holds the best move , score and bounds. Main reasons why you could do this are : 1) Since I do checks , threatening moves and all check evasions , it helps me immensively - both in move ordering and also by giving me cutoffs (much lower though). 2) You could also use this same table to also store the evaluation of the position - thereby saving an expensive eval() call ! note : assuming no search tree path dependent terms in eval - if yes , you could split the eval() into only position dependent and rest (path dependent) components and store the position dependent stuff into the table. Currently I follow always replace multiprobe , with positions near depth == 0 getting slightly higher precedence - you could do it different though ... As always , YMMV Regards Mridul
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.