Author: Don Dailey
Date: 18:55:21 01/30/98
Go up one level in this thread
Stuart, You can use many methods to cut sort time to almost nothing. A) first of all, don't sort at all if too near leaf nodes (do some tests to see) B) Do on the fly sorting. Don't try to order all the moves, just find the next one. C) Only sort n moves, the rest become much less relevant. I used method C a long time ago and it worked well. I think I used the history heuristic and only sorted in the first 5 or 10 moves or something. It did 95% of the work. The final result was almost all the node reduction benefit and no noticible slowdown in nodes per second. Your first test of course is to see if it reduces the tree size and then worry about speed which I presume you did. - Don On January 30, 1998 at 15:15:34, Stuart Cracraft wrote: >Presently, I don't sort but use a move selection method (pick >highest score from amongst the set of moves). Since N is large >in this case, it is inefficient as well (as if it sorted.) > >The main problem is that move generation is done too much and too >often and I don't have a routine for simply legality-checking >a move (hash move, killer move) without having to do a move >generation. > >The search should be in phases of types of moves generated or >being investigated without generation. Won't be hard. Just a >switch/case-like statement with the same code doing slightly >different things depending on the type of move being legality >checked or generated. > >I do have the capability presently to generate captures without >generating non-captures and will roll it in. I do have hash >move and killer available but presently do a move generation >before them. After putting together a legality-checker routine, >I can search them directly without the move gen. > >Thanks for the helpful feedback, > >--Stuart
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.