Author: Robert Hyatt
Date: 11:33:06 08/24/99
Go up one level in this thread
On August 24, 1999 at 10:05:53, Inmann Werner wrote: >On August 24, 1999 at 09:57:43, Robert Hyatt wrote: > >>On August 24, 1999 at 05:39:54, Inmann Werner wrote: >> >>>Hello all! >>> >>>I am again trying to tune my program, and came to some questions. >>> >>>1) >>>What to do with fail lows and hashing. >>>Put them in for move ordering? I think no. >>> >>>Put them in for hash hits? >>>I do, but I am not sure, it is good. >>>If I get a hash with fail low flag I check, if it is again a fail low and only >>>then I use it. >>>That makes a cuttoff for easy, not disturbing? >>>But in positions, i get differences, if I use fail low hash hits. Not much, >>>but...? >>> >>>What do you think about doing best? >>> >>> >>>2) >>>It disturbed me, that in some not clear positions the search often switches, and >>>that only for 1 point better (1/100 pawn) which is not real relevant, but costs >>>much time cause of the research. >>>So I thought about making the eval result not so perfekt (score=(score/2)*2). >>>Now it switches not so often, but in "normal" positions needs more nodes (less >>>cutoffs?). >>> >>>Is this idea dumb or worth thinking about it. >>>Makes a small evaluation, where much values of different positions give the same >>>value the search slow? >>> >>>Werner >> >> >> >>I don't quite understand, but you have only three cases to handle: > >Yes, I have always problems to say my problems in English :(( >> >>1. When you complete a ply, and the score you found was > alpha and < beta, >>you store the score, and EXACT. If you later get a 'hit' and find this >>position, assuming the depth is sufficient, you just return value without >>doing any more searching at all. >> > >Clear! > >>2. When you get a fail-high at a node, you store the value you got (which was >>>= beta) along with a flag LOWER (to note that this is a lower bound on the >>score, that it might actually be higher than this). When you get a hit on this >>type of entry, you only need to verify that your current beta value is < the >>bound stored in the table, and if so, you return the table value without >>searching further. >> > >clear! > >>3. When you get a fail-low at a node, you store the value (alpha or less) >>and a flag UPPER (this is the best you can do, the worst score possible could >>be even lower). When you get a hash hit, and your current alpha value is > the >>table bound, you just return the table bound with no further searching. >> >>That's all there is to it... > > >Then you say, fail-low = UPPER entrys in hash should be used for hash probes!? > >My question. Should these entries also be used for move ordering? > >Werner 1.. think about a fail low like this: you are doing an N ply search, and at ply=5 you search all moves and the best score is still alpha, so you return alpha here, correct? Assume you search further and you reach this same position again, at the same depth, with N the same also. Before, when you searched this position, you returned alpha (failed low). Why would you _not_ do the same thing this time? And the has table saved you all that searching. 2. there is no move ordering info for a fail low hash entry, because at a node marked UPPER, you searched _all_ moves and each one returned alpha, so that there is no way to differentiate between them. I store _no_ move in the hash table for such entries, so they affect move ordering not at all...
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.