Author: Robert Hyatt
Date: 20:57:32 09/18/04
Go up one level in this thread
On September 18, 2004 at 18:50:22, Richard Pijl wrote: >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. > I'm not sure why it would matter. You should fail high, relax the upper bound, and get the _same_ value back except this time it will be an exact score... That is pretty normal to get a fail high and then on the re-search, getting the same score again since the upper bound and true score were identical... This doesn't cause oddball PVs in Crafty however, even though I see it on occasion... (see the identical score/upperbound problem, but no illegal moves in my PV ever). Nor did it ever happen when I used true fail-soft years back... >>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.