Author: Bas Hamstra
Date: 07:54:53 01/17/00
Go up one level in this thread
It should work. I used this a while ago with ab (in stead of PVS) and it didn't give any problems. I don't see why it wouldn't work with PVS. 3L raises Alpha and 3U decreases Beta. If you get a fail high on that window there is a search inconsistency. An earlier search said "v can't be higher than X" and then research returns v > X. Does it still occur with nullmove turned off? Nullmove causes search inconsistencies, which is normal. A different ab window lets nullmove prune different branches. Regards, Bas Hamstra. On January 17, 2000 at 10:23:13, Peter Fendrich wrote: >When searching the hash table, I've detected basicly 9 different states. >The value from the table is a Lower (L) or Upper (U) bound or Inside (I) it's >A/B-window. >For each of these we have 3 cases: >1. value <= current Alpha >2. value >= current Beta >3. current Alpha < value < current Beta > >Combining it all we have: 1L, 1U, 1I, 2L, 2U, 2I, 3L, 3U and 3I > >For now I'm interested in case and 3U. >When we have 3L, we know that the table entry is the lowest >possible value and that the current Alpha is lower. To me it seems >reasonable to set current Alpha = table value. >For 3L this will be: current Beta = table value. > >That doesn't work well with my program which has a PVS-based alg. >When re-searching a move, the A/B-window will be narrowed down in >the tree based on the 3L and 3U cases above and a FailHigh together with >a cut PV-line will be the result. >I have tried to set current Alpha = value-1 and current Beta = value+1 >with a somewhat better result but this doesn't "feel" right! > >Now I've turned the thing off completely and can sleep at night again... > >Something is wrong here. >Comments please! > >//Peter
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.