Author: Inmann Werner
Date: 13:05:50 08/24/99
Go up one level in this thread
On August 24, 1999 at 14:33:06, Robert Hyatt wrote: >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... Thanks! It is the same conclusion (but in much better words) I came to. So now I can sleep good.... :)) Werner
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.