Author: Gerd Isenberg
Date: 12:46:01 07/24/04
Go up one level in this thread
On July 24, 2004 at 04:51:39, Stefano Gemma wrote: >On July 23, 2004 at 18:33:36, Gerd Isenberg wrote: > >>Is your getNextMove O(N**2)? >[...] > >To avoid moving data forth and back from the memory, i've tried two approach. >The first one, since my old Drago and Raffaela, was to search the next move, >without ordering the moves (we have already talked about this, in this forum, >some year ago). A simple variation to this approach is to store the best move >generated, as the first move to try (this is done directly by the move >generator). Then we search the next best move, any time we need it. This could >be expensive, if you're near the root, because the most of the moves are always >played, but is helpfull when you're near the leaves, beacause the most of the >moves were pruned away. > >The second way i've tryed for getNextMove, in the new engine Freccia, is... not >to store the moves at all!!! It seems very strange, if you don't store the >moves, how can you find the best one? I've considered that, with my move >generator, i need from 2 to 4 assembly istruction, to know if a move is legal. >If i store the legal moves, i need some extra 3 or 4 assembly istruction to save >piece and delta (i use 0x88 like chessboard rappresentation). After stored the >moves, i need to have a loop that search the best one. I can avoid this loop, >because i need only 2 istruction, to know if a move is legal, why to store the >move itself? I can just add the test for the best one in the move generator, >without to store the moves (except the best one or the its index). This stuff >works well, but it is almost impossible to implement in a satisfactory way, when >you implement Iterative Deepening, because you need somewhere to store the value >returned from ID iteration and associate it to the right move. In the nodes far >from the root, it is tremendously efficient, but just for nodes where you need >only one move to prune. I'm experimenting on a mixed approach, but i'm a little >busy with my work, since ten years ;-) > >Ciao!!! > >Stefano Gemma Hi Stefano, that sounds interesting. I guess your engine is pretty fast ;-) I like the idea of a finite state generator too. If some concrete moves for a node are feeded back by hash, killer-heuristic and probably hints from eval, it is nice to check for legality only and then to make the moves, hoping for a cutoff. Anyway one needs some bookholding to don't generate and make those moves twice of course. But i don't see any reason to use different data structures or interfaces for those suggested moves - all a kind of movegen states and bookholding. Cheers, Gerd
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.