Author: Jeremiah Penery
Date: 06:02:29 12/01/99
Go up one level in this thread
On December 01, 1999 at 07:50:34, Inmann Werner wrote: >On December 01, 1999 at 07:13:34, Inmann Werner wrote: > >>On December 01, 1999 at 05:40:12, Jeremiah Penery wrote: >> >>>On December 01, 1999 at 04:43:06, Inmann Werner wrote: >>> >>>>On December 01, 1999 at 04:27:03, Jeremiah Penery wrote: >>>> >>>>>On December 01, 1999 at 02:50:01, Inmann Werner wrote: >>>>> >>>>>>On November 30, 1999 at 20:04:00, Gerrit Reubold wrote: >>>>>> >>>>>>>Two Months (?) ago we had a thread "what should we store if all moves fails >>>>>>>low?" with the answer: Nothing! There should be a saving of a few percent of >>>>>>>treesize if you don't store "random" moves in the HT. Maybe this could be an >>>>>>>improvement of your algorithm? >>>>> >>>>>>Why stuff in nothing at fail low? >>>>>>fail low is bad for move ordering, so I do not use it there. Ok. >>>>>>But for normal hashing, I use fail low, if the value<alpha. At mate values, I >>>>>>give back something like mate in 500....(brings my prog to sometimes not show >>>>>>right "mate in #", bothers me not much) >>>>>>I overwrite fail low values first, cause they are the "less value" entrys. >>>>>>Why should I search all moves, only to recognize, that it again is a fail low? >>>>>>I see nothing good in it. >>>>> >>>>>The idea is that when you have a fail-high node, ALL of the next-ply moves have >>>>>failed low. In this case, you should store nothing in the hash table, because >>>>>you don't have a good move to store. If you do store a move here, it's as good >>>>>as storing a random move, because any of those moves can turn out to be the >>>>>WORST move. They all failed low, and here the algorithm will not tell us which >>>>>one is the best; they must be re-searched. Storing a move here will hurt move >>>>>ordering, because you keep getting hash-table hits that tell you to search this >>>>>move first, even if it turns out to be the worst move. >>>> >>>>Some misunderstanding maybe... >>> >>>Probably. :( It's probably because I'm not explaining myself well. >>> >>>>I have a flag in the hash, if the entry was fail low or fail high. I never use a >>>>fail low move for move ordering!!! >>> >>>This is good. :) >>> >>>>The only info I use is, that the move failed low and the evaluation value it >>>>got. If the search window alpha-beta is not open enough, the move will fail low >>>>again. Why search again? >>> >>>At a fail-high node, it means that all the opponent's next moves have failed >>>low. If you don't research something, then what do you search? You'll have to >>>research at least one of these with a wider window, or you will just keep >>>failing high because you're just taking "FAIL-LOW" from the hash table every >>>time. >>> >>>>Also, if the value gives something like mate in n, i use it as mate in 500-n. >>>>The PV leads to a mate, why not use the information.... >>> >>>I wouldn't be too worried about this in any case, unless it says "Mate in X", >>>and then on subsequent moves it keeps saying "Mate in X" or "Mate in X+Y", >>>instead of "Mate in X-Z". I.e., as long as it makes progress, it probably >>>doesn't matter. >> >>No we understand each other :-) >> >>Maybe the problem, we talk about never occurs? >>I stuff the fail low value in the hash. If it comes out to be the PV at the end >>of the search and then it will be researched with open windows and >>overwritten-never used. >>What happens with the "fail low" in a dead branch. Each move is blunder. >>Somewhere up in the tree must have been some big blunder, the prog recognizes, >>and stuffs the better move in the hash. At some side trees the prog also comes >>to our fail low position with a closed alpha beta window. Now what do? let the >>prog search the moves to recognize the fail low or tell him, hey, it will be >>fail low, get back and do what is to do. >>If you search zhe same pos with deeper depth, the hash value would not hit cause >>the depth info of the value is too bad. >> >>To stop a endles debate, I will try it now in my prog. Both versions with some >>positions. Lets look, if anything changes... >> >>Werner > >I tried it. >I only changed one line in my prog preventing, that fail lows go into the hash. >checked it 3 times. >now I am fully confused!!! >The difference is a lot!!! >(new=without stuffing fail lows) >the two versions in same plys often do not get the same PV!! >at Lctcmb01, the old version finds the move in ply 7, the new one in ply 8. (the >only better one, but suspicious) >in Lct Endgamepositions, the new version searches 1 to 3 plys deeper!!!!! >Especially when fail high in the pv occurs, the old version needed very long to >research. >OK. I will not use the fail low hash anymore, and my endgame improves some ELO >(1-3 plys?), but I must say, I understand nothing why it is.. >I checked everything, and the hash entry is only used for stopping the search, >if the found value is lower than alpha. But at a fail-high, EVERY MOVE for the next ply failed low - they will ALL be less than alpha. I'm not sure I totally understand what you mean about stopping the search, though. If you get a fail-low, you stored it in the hash table and then when you found that value in the table you simply didn't go any deeper after that? If this is what you were doing, it could cause some problems, because you will delay the research unnecessarily for another ply or two. I guess if you have lots of these in your tree, (like in endgames, where you get more NPS, so more nodes and a bigger tree) it can really hurt, but I'm not sure. Also, how did you previously do move ordering before when you got a fail-low? > Have this in since "ever", never thought >of any problem with it. Do not think of a bug.... >Maybe the problems occur in interaction with NullMove, PVS, and pruning.... I'm not sure...I'd like to understand this more fully as well, at least in your case, since you weren't using the fail-low information for move ordering.
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.