Author: Robert Hyatt
Date: 14:21:51 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. > >Small but important difference. :) Nope. I store bounds as they exist in the search at the time of the store. I update the bounds with exactly what I get from the table... > >>>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 just can't happen. When you back up a real score, you back up a PV. The farther back up the tree that score gets backed up, the farther back up the tree the accompanying PV gets backed up. PVs only get _set_ when we stand pat in the q-search, or get an exact score from the hash table. Otherwise they only get backed up along with the score. I don't see how the PV can get randomly clipped. Mine doesn't... > >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? Why does it have to to have a correct PV? The PV is just something that goes with the score... > >-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.