Author: Dann Corbit
Date: 23:05:22 02/07/03
Go up one level in this thread
On February 08, 2003 at 02:02:09, scott farrell wrote: >On February 08, 2003 at 01:31:00, Dann Corbit wrote: > >>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. >>> >>>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. >>> >>>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?" >>> >>>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. >> >>It's an interesting idea for tactical positions. It makes me nervous when there >>are a large number of moves within a few centipawns (e.g. the opening position >>and positions like it) where there is no clear cut winner. >> >>On the other hand, if you have a sure ELO increase, it may well be something of >>great value. It just "sounds funny." > >The ELO increase probably includes a few other changes. > >As you say, where there are no tactics - largely positional - it isnt a huge >winner. But what you do get, is at say ply9, your best move checked for safety, >and everything else checked for obvious winners but only at depth8. So it is >playing a safe move, and not necessarily its best move. > >With it becoming more and more obvious (was it your post?) that a computer >doesnt win a game, it just doesn't lose, and waits for the opponent to blunder, >this code plays safer chess, and doesnt blunder itself as much. > >I found a small suite of problems that crafty had problems with, it would find >one move at say ply6, at ply 7 it immediately found it looses, and suggesting >something, at ply 8 the second suggestion is found to be floored and suggests >another move. The problem is, it is spending approx 50% of its time trying to >find a better move than the blunder it is about to unknowlingly play (ie. PVS >search of moves 2-35). > >Chompsters code in these positions, given it is tactical, uses many many less >nodes (than with chompster without the code) in finding the dangers. Chompster >spends more of its time verifying the current move is good, and looking hard for >alternatives when it finds it is about to blunder. > >If there are X good moves within 1 centipawn, then taking any one of them at >random is not going to loose the game. What is going to lose, if the one you >choose does have a tactical mistake in it at the next ply. > >Overall, I think it just skews the nodes to more searching your PV, and less >looking for alternative PVs. It might not find as many brilliancies as quickly, >but less often make a move that blunders. > >I have found that chompster makes less sacs, but that is more of an observation >than anything. It is certainly an intesting idea. And, in reality, it is easily as logical as null move (which will also cause problems on rare occasions). I'll probably fool around with it some.
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.