Author: Robert Hyatt
Date: 07:31:37 02/08/03
Go up one level in this thread
On February 08, 2003 at 00:50:22, scott farrell wrote: >My idea relies on an underlying use of PVS search (principal variation serach), >an aspiration window, and IID (internal iterative deepening). > >When searching the root position, I search the first move as per normal. > >Then I search all remaining root moves at depth-1, basically everything gets a >reduction. This speeds the already fast PVS search. If any of the PVS searches >at root fail require a research, I research without the reduced depth. > >If at any time I fail low at root without a PV move already, then you panic and >add time etc, and dont do any depth reductions. The question that has to be asked is this: "what justifies comparing the results of a depth D+1 search for the first move at the root to a depth D search for the remainder of the root moves?" All this does is introduce horizon effects on the remaining moves as they are searched less deeply. If you are doing null-move properly, the rest of the root moves take only a small fraction of the time (combined) that the first root move requires to search. > >If you fail high, I often just take the move if its near to the time allowed for >this move, especially if its value is more than our last move on the board. This is yet another problem. You just failed high on a search one ply less deep than the search you are failing high over. What happens if you were to re-search this move with the right depth and it fails low way below the first move's score? > >The idea is based on a few thoughts: >"why do you try ply 9 when you already have a nice move on ply 8" >"are you trying to ensure the move is safe?" >"are you trying to find a better move?" The latter. > >I think proving your move is safe is far more important. And that is what my >idea above does. It spends more time on checking that your move is safe, rather >than looking for a better move. This really helps, when there are 2 candidates >moves, and they are very close in score, and your engine spends lots of time >flip-flopping between them as best. My idea disregards the second, until it can >be shown it is much better. > >When you have finished searching say ply8, you have really only searched ply8 >for the best move, and ply7 for everything else, unless you found a problem with >the best move and panicked. > >In positions where you have 1 clear good move, things really get an amazing >boost. In positions with lots of traps, it takes just as long as normal (ie. no >slower), but finds the traps more quickly, and during a game gives you the fail >low more quickly in order to allocate more time. > >I implemented this in chompster, and it seems to have had no drawbacks. It has >been averaging around 2450 on ICC in recent weeks, pretty good for Java !! > >This will be especially useful for 'newer' engines that arent real good on time >management, and only search full plies at the moment - this sort of allows you >to search partial plies when it is safe to do do. > >Let me know what you think, and if you might give it a try in your engine. > >Scott
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.