Author: Dann Corbit
Date: 16:55:01 04/28/00
Go up one level in this thread
On April 28, 2000 at 19:15:59, José Carlos wrote: >On April 28, 2000 at 17:22:24, Dann Corbit wrote: > >>On April 28, 2000 at 17:01:20, Severi Salminen wrote: >> >>>Hi! >>> >>>My program finally has AB search, searches some 70 KN/S and it almost knows >>>every rule (no underpromotion, 50 move rule and position repetition :-). Now I >>>would like to add some move ordering. I have two simple ideas: at root I sort >>>the moves by scores from previous iteration and at other nodes maybe by >>>captures, checks and then others. Does this sound reasonable? Where could I find >>>more information on move ordering methods or what do you use? >> >>Sort them by time it takes to emerge from alpha-beta. >>The ones that take the longest get checked first. Resort after each new level. > > I don't get the idea. First, when using PVS, PV move will always take more >time than the rest (if not fail high). But, omitting PVS, I don't still >understand why a move that takes longer should be searched first. > > What I do right now is: > 1.- in the first iteration, I sort the root moves exactly the same as the rest >of the moves (captures first, etc.). > 2.- after every fh, I assess that move a value greater that the others, so it >will be searched the first in the next iteration. > 3.- as new fh occur, the moves remain ordered as last_failed_high_first. And >the moves that never failed high, remain ordered by normal ordering heuristics. > > This method seems to work fine for my program. The reason the slowest positions might get searched first is because they are promising. It took a long, hard look to decide that the other one was better. If we returned instantly, then it's not worth looking at.
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.