Author: Robert Hyatt
Date: 05:20:41 10/23/97
Go up one level in this thread
On October 23, 1997 at 07:46:07, jean-christophe WEILL wrote: >On October 23, 1997 at 02:43:12, Reinhold Gellner wrote: > >>Doing a zero-window search, fail high moves have to be re-searched. >>Usually I do it with >> >>actual_value = -re_search( -beta, -actual_value ); >> >>However, as extensions or just move ordering changes, the re_search is >>not neccessarily the same and may result in a fail low! That is, >>actual_value is now below the former actual_value but >= alpha. >> >>I think this is a common problem. I have three solutions: >> >>1. ignore this fail low at all >>2. do another re_search: actual_value = -re_search( -actual_value, >>-alpha) >>3. do the initial re_search an open window: >> actual_value = - re_search( -beta, -alpha ); >> >>ad 1) this version may be dangerous in blitz games and of no importance >>in tournament games, resulting in a speed up. > >.Sometimes it may help you to lose games . Not only blitz one ! >if the fail low occurs just near the root. > This behaviour is described in my thesis and much of the time this >is a result of a heuristic cut-off(or extensions) which depends on the >alpha-beta values. > there are other causes too, most notably the trans/ref table. You search along, and reach a node P with depth remaining=5, and after searching below that node you return back and fail high. Later you reach node P with a different sequence of moves, with depth remaining=2, do a table probe and find the fail high which you use. Then you back this up all the way to the root which fails high. You re-search, with a larger beta, and now P can't fail high. But with only 2 plies left (you need 5 to see the real things that are going on) now you can't fail high, and you can't see why you failed high before, so you fail low. I don't trust these and throw them away. I saw cases in Crafty, before I modified this, where this fail high move was bad, and was actually caused by a null-move acting up on occasion. This *definitely* lost games on the chess servers. I eliminated this before Jakarta last year, and have had no odd behavior since. Fail high followed by fail low is ignored for me. > > >> >>ad 2) the second search may now fail high again, or even oscillate, >>resulting in an eternal loop. > >> >>ad 3) this safe approach seems to significantly increase the effective >>branching factor. >> > >When you extend the window, normally the transposition table value >should reduce it at the childs node ! Giving you no benefits for window >extension. But that is the good thing to do with some special flag >preventing the transposition table effect. This saves games even if >this also slow down your program a little bit. > >BTW in 1), everyone should check its code to know which of the move >is chosen as the best move, especially if you are at the root. > > >JC
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.