Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Moves per position.

Author: Frank Phillips

Date: 10:55:44 11/27/98

Go up one level in this thread


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?

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.

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



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.