Author: Richard Pijl
Date: 02:42:20 09/18/04
Go up one level in this thread
On September 18, 2004 at 04:05:38, Sune Fischer wrote: > >I decided to try out the triangular PV thing Bob >speaks so highly of, to see if it improves move ordering... > >I was careful to terminate the PV on all exact scores - of course. >Still I was getting illegal moves in the PV. > >It turned out to be a hash/nullmove problem. > >See, in the hash I adjust the window down on UPPER bounds, ie. >something like: > if (flag==UPPER && score<beta) > beta = score; > >The idea is that if we know the score is in the interval [x,y] >then there is no reason to search with a window of [x,y+z]. >It's a common trick I believe. > >Unfortunately, the search will occasionally fail high on the new beta, in my >case it was a nullmove that failed-high. > >That's clearly contradictive with what the hash just told us so >it doesn't actually make any sense, but apparently it happens anyway >(instability?). > >Now the score at the previous node might be an exact value (or a fail high later >on), and the PV will now be concatenated from an old search branch. > > >I can't see that I am doing anything wrong. >Perhaps adjusting beta is just not a good idea? > >-S. As far as I can see there are two problems (I encountered both of them myself :-): - Even in a stable search you cannot set beta to the upperbound found. The upperbound is an inclusive bound, so the bound could be the real score. This problem is easily solved by setting beta=score+1; - In an instable search, when you get a fail high on the adjusted bound, the returned score is seen as an exact score as it will be within the alpha-beta window. I don't think this problem is solved easily. Instead you'll have to research with the original a-b window. I'm not sure that is worth it. Richard.
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.