Author: Uri Blass
Date: 15:04:38 06/17/02
Go up one level in this thread
On June 17, 2002 at 11:30:28, Robert Hyatt wrote: >> >>It is also obvious that if I do not clear the hash tables after every move >>replace only when you have bigger depth is a mistake because you are going to be >>left with old nodes that are not important and my first implementation of hash >>tables was without clearing the hash tables. > > >This can be fixed with an "age" field. first, use depth-preferred only if >the position is from the current search, otherwise keep it but overwrite it >whenever you want to store, regardless of the age. I do this in Crafty and >it works well. > >I also use two tables in crafty, one is "depth-preferred" as you explain, >the other is "always store". I _always_ store a hash entry in one or the >other, most often the latter. > > > > >> >>I remember that I did not find clear advantage for replace only when the depth >>is bigger but it may be also a result of other problems. >> >>I decided to record moves in the hash tables only when the score is bigger than >>beta because my tests showed that it is better than other options that I tried >>inspite of knowing that in theory it should not be the case. > >You should store a best move when score > alpha. If score == alpha, you >won't have a best move, but in all other cases you will. > > >> >>Inspite of all the problems and the fact that hash tables are used only for >>better order of moves test suites proved that hash tables made movei clearly >>faster(about 1.5 times faster relative to movei without hash tables). > >That is normal for middlegame positions. You don't get many "EXACT" type >hash hits. But try fine # 70 and this will change. Movei does not use hash tables to prune the tree but only for better order of moves so I am not surprised if it's search is not good in endgame positions. Note that Junior4.6 had also serious problems in simple endgames and I suspect that it did not use hash tables to prune the tree at that time but I do not know because I did not ask Amir. Note that it is not trivial for me to decide to use the hash tables to prune the tree. One reason is that my search rules are not trivial and I use the values of alpha and beta for it's extensions and pruning rules in some cases so it does not seem safe for me to prune a line only because I have a score at the same depth for that line. Another reason is that I have not one variable to define the real remaining depth. I have one integer that gives me the remaining depth in plies and another integer that gives partial extensions. I may consider using the hash tables to prune the tree only when the depth is clearly bigger and not equal to the depth in the hash tables but before doing it I think that it is better to improve the use of hash tables for order of moves. I have some well defined problems to solve that may give me hints about it. There was a game when Movei lost against gnuchess when the last move of movei showed that movei let the opponent to do a mate in 1 when the score was only longer mate. Movei saw the mate in 1 at depth 2 and changed it's mind but later it changed it's mind again after it saw that other moves are also losing and forgot about the mate (it has -20 or -30 score at depth 4 and later discovered a longer mate at depth 5). It means that there is some problems in the way that it is using the hash tables because it should not forget mate in 1. I guess that not seeing the mate in 1 may be because of some pruning that is dependent on alpha and beta and I will try to find the problems tomorrrow. Uri
This page took 0.01 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.