Author: Robert Hyatt
Date: 16:13:22 06/17/02
Go up one level in this thread
On June 17, 2002 at 18:04:38, Uri Blass wrote: >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 If you store a mate score in the hash table (I do) then you must adjust it to be "mate in N from the current ply" not "mate in N from the root". If you fix that right, mates work just fine...
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.