Author: Richard Pijl
Date: 15:50:22 09/18/04
Go up one level in this thread
On September 18, 2004 at 11:28:45, Sune Fischer wrote: >On September 18, 2004 at 11:09:26, Robert Hyatt wrote: > >>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; >> >>Are you doing PVS? If so you won't do this a dozen times during a long search, >>most likely. But I do this in Crafty as well, and it doesn't _ever_ get illegal >>moves in the PV. > >I haven't looked but I guess you are doing something equivalent to what Richard >suggested with beta = score+1. > It may be less important when doing fail-hard. Chances that the upperbound equals the real score is lower with fail-hard. Richard. >Small but important difference. :) > >>>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. >>> >> >>That can't happen. You don't update the PV on a fail high, ever. Only if score >>is > alpha and < beta... > >The PV is not updated on that node either, it's updated above at the parent node >because here the FH-score will fall within the window. > >And of course that will result in a random clipping of the PV. > >This doesn't seem possible to prevent a 100%, because how do we guarantee that >the new search will produce the same score as the old one when the hash has been >changed meanwhile? > >-S.
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.