Author: Robert Hyatt
Date: 19:48:49 11/28/98
Go up one level in this thread
On November 27, 1998 at 16:31:13, Christophe Theron wrote: >On November 27, 1998 at 13:55:44, Frank Phillips wrote: > >>On November 25, 1998 at 14:42:52, Christophe Theron wrote: >> >>>On November 25, 1998 at 13:23:42, Frank Phillips wrote: >>> >>>>I am disappointed with the number of moves my program analyses per position in >>>>the main search. With basic shuffling to the head of the move list of the pv >>>>move, hash table refutation move and capture of valuable pieces by less valuable >>>>pieces, the search is making around 9 moves in each middle game position and >>>>about five in the endgame. A few more with the sorting turned off. What is >>>>normal? >>> >>>What do you call PV move? >>> >>>The move given by the hash table should be tried first IMO. You should also use >>>killer moves. >>> >>> >>> Christophe >>Thank you for the advice. Had not tried killer moves before. My initial >>impression from some very quick, very unscientific tests indicate that they have >>not helped. The nodes needed to reach the same depth went up by at least 20% >>and sometimes 80%. The refutation hash table and considering captures first >>seemed more important. Perhaps with refutation hash and history heuristic >>table, killer moves are less important? > >They are less important but still absolutely necessary. > >There is something wrong in your implementation I suppose. You should find >killers to be VERY useful. > this depends. If you use the history heuristic, killers don't do much better on top of them... but there is a gain, because with "killers" you can try them before generating moves, while with history moves you have to generate moves first. This gave me a modest savings, but the size of the tree didn't change much at all, but I used history before I used killers... > >>Could be wrong since the testing was weak; and I may have not implemented the >>killer moves properly. I simply stored two killers for each ply (killer1[ply] >>and killer[ply]), storing killer1 in killer2 and the new move in killer1 if it >>caused a beta cutoff. If the killers were in the move list at the current ply, >>these were searched first - and they were on many occasions. > >Your description sounds correct to me. But check this: > >Try them after the hash table move. The HT move should always the first move you >try. > >If you search captures before the other moves, try without storing captures in >the killer tables. > >Try killers before or after the captures. Compare the 2 versions. From long experience, the right order is the following: 1. hash move 2. captures that appear to gain material 3. 'even' exchanges (captures that don't win or lose material) 4. killers or history heuristic moves 5. rest of the moves. I can't imagine a case where winning captures should not be searched before anything else, excepting the hash move, because it was best in this identical position before, it should be best now most of the time. killers can't be captures of course, because you have already tried the good captures *first*. So don't let captures get into the killer moves at all. > >Try with and without killers in the QSearch. Depending on your program it may >impact in the wrong direction. > if you do non-captures in the q-search, killers may make sense. I did them in cray blitz and it worked fine. But if you only do captures, then killers don't help at all. > > >>Still interested in the number of moves per position it is normal to have to >>search. As I said previously mine is searching on average around 9 moves in >>each middle game position, which seems a lot > >At what time control, on which computer and with how many HT? > >In assembly or with interpreted Basic? > >And on which planet? :) > > > Christophe impossible to compare. different extensions, random differences in move ordering between programs, different evaluations, etc..
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.