Author: Daniel Shawul
Date: 04:42:04 08/27/05
Go up one level in this thread
On August 27, 2005 at 07:21:11, rasjid chan wrote: >On August 27, 2005 at 04:18:58, Daniel Mehrmannn wrote: > >>On August 27, 2005 at 04:04:40, Daniel Shawul wrote: >> >>>On August 27, 2005 at 01:42:32, rasjid chan wrote: >>[...] >>>>4) retrieving the PV. >>>> This was discussed over at the winboard forum but I am still not too clear. >>>> We have :- >>>> a) the pv[ply][ply] method. But hash probe returns on exact usually make >>>> the PV short. Is this superflous when there is hashing? > > >>> You can have longer pvs if you don't use hash tables at PV nodes, if you >>>dont use null move at pv nodes, if you don't use other prunings at pv nodes. >>>But are you ready to pay its cost? > >Daniel, >I am not too clear here. (Ignoring pv length)Nullmove and prunning seems >unrelated to this retrieval pv issue. It is about THE PV LINE. > Null move if done at pv node cuts the pv. Ofcourse in this case search will fail high/low at the root. Anyhow we will get a shorter pv. Ditto for other prunings. On the research with wider window, we will have longer pvs since null move will not cause fail high at the pv node this time around. If you always use -INF,INF IE no aspiration, your pvs will not be short except for those caused by HT hit (since this can store exact results). Other prunings will not occur on the pv since alpha is -INF at pv node. hope i got it right. daniel >Say nullmove cause cutoff, so no new pv otherwise normal search may return the >node as exact in which case this node may be in the next pv and this matter. >(Perfect )Pruning is not supposed to prune away the potential new pv. The point >from Vincent is that when we returns to root, the new pv nodes are all intact in >the hash table. So the next iteration just makemove() for all the bestmove from >the hash table provided none was overwritten. So this mean we don't need to keep >pv[][] if we have hash tables (it is like double accounting). Of course I may >want to take some care (set flags, etc) under certain circumstances not to >overwrite exact entries(UB/LB ok) of higher draft/maybe entries within the same >search sequence.etc.Vincent Diepeveen seem to think no problem at all, but I >don't know with certainty what is the "safe or correct" method. > >> >>For a better search daniel's Shawul hints are fine here, but this has nothing to >>do for having longer PV's. > >>May you set a flag if you're have a hash hit and if you're finished your search >>or each new interation you can > >"... extract your pv from your hash easily ..." > >I dont know how(why?) to extract. > >This is the question. IF all of the pv entries in the hash table are there, >we do nothing - just continue the next iteration. This is my question > >>This is allso good vs overwriting hash entries. >> >>Best, >>Daniel
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.