Author: David Mitchell
Date: 13:22:28 03/09/04
Go up one level in this thread
On March 09, 2004 at 06:59:13, Bert van den Bosch wrote: >On March 09, 2004 at 03:23:13, David Mitchell wrote: > >>On March 08, 2004 at 22:09:38, Bert van den Bosch wrote: >> >>>Hello all, >>> >>>Just to tell you I joined this forum today. My name is Bert van den Bosch from >>>the Netherlands, and I've started programming an engine in java, which can >>>already play on icc. >>> >>>Actually I've a question. I have chosen some particular structure for my >>>program. That is, a table which keeps track of all possible moves. In other >>>words I don't have a move generator(well implicitly I have, off course the moves >>>have to come out), but I adapt my movelist when I do piece inserts and deletes. >>> >>>What I want to be doing is trying to store a move, and its implications on the >>>board and try to find it later when the same move comes up in the search tree, >>>and when the move is locally the same (as in it affects the same pieces on the >>>board) then I'd be able to make the move faster and know already the change in >>>value of the position. It's somewhat like searching for the same position which >>>I guess is well known, but on a local scale. >>> >>>Anyone any experience with this? >>> >>>I've already tried it, it had some bugs, and I found that in about 80% of the >>>times the move already made before could be applied again. In which case my >>>program is able to make the move (node) 10 times faster so it would be nice if I >>>could find the move fast in some nice datastructure. >>> >>> >>>greetings Bert >> >>Welcome to CCC, Bert. >> >>Just an amateur programmer here, to be sure, but have you thought about using a >>transposition table for this? (AKA a hash table). They provide quick access to >>your program, but store positions, not moves. Other than that, sounds like just >>what you're looking for, along with a "killer" moves record (usually 1 or 2 >>moves for each level of the search tree). >> >>I'm curious how your table of moves as a move generator, compares in speed with >>a more "normal" move generator, any comparisons you've made and would like to >>share? >> >>dave > >Yes I read about that stuff, but I wanted to make a different setup, just by >choice, trying to see if I can make it respectable fast, which I hope might be >done. > >Are killer moves hit moves? > >Now it is very slow indeed, but you know a lot about the board. I started out >with a normal move generator but quickly came to the point of move ordering. >Indeed that was very fast but move ordering very bad, now it is the other way >around. Well maybe I should just progam a bit longer, hoping to get it fast :) > >greetings Bert Killer moves have nothing to do with a "hit", glad to say! :) Killer moves are moves which stop you from making a great move of your own. They sharply refute (usually several), strong moves that you could make, except for their presence. The idea is say you have a great attack you could mount, _except_, that the opponent could play his rook to the back rank and checkmate you. So the rook moving to the back rank would be the killer move to try first against any move of yours being evaluated. If it's a killer at ply 4, it will quite possibly be a killer at deeper ply's, as well. In the overall ordering of moves, killer's usually work best being considered just after captures, but every engine varies according to their own specific logic. Congrats on having your engine already on ICC. dave
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.