Author: Marc Boulé
Date: 08:00:32 09/02/02
Go up one level in this thread
>1. I am sure many people have thought of this before, but there must be faster >ways to updating lists of legal moves, other than using brute force. Obviously, >the program would not check every possible square, but only a list of pieces. >My question is: would it be faster to set flags for each piece, and only update >a piece's list of possible moves if one of the flags has been tripped? > >For example, if an h pawn moves, it seems almost silly to have to update the >list of possible moves for a knight on the a column, and simply check to see >whether or not the list of moves for the knight needs to be updated, and if not >(as in this case), know that the list of moves has not changed. > >Do programs already do this? Or is this inefficient or even incoherent in some >way that I do not realize? I have tried such a move generator. I called it a differential move generator as it computes only the differences in the move lists for all pieces (white and black). I had the same idea as you: if you do a3, a large majority of pieces are unaffected and their move list doesn't change. I was sure it would be better than my basic move generator (not bitboard). After a partial test (no promotions, en-passant, or castle), I was dissapointed to see that it was only 1 or 2% faster on average. It is often good to do a test before coding all the ugly chess moves just mentionned. In this case, the normal move generator has the ugly moves disabled so that the comparison can be valid. I was sure that a differential move gen would be faster. In my case, it wasn't. I hope it can work for someone else though... Marc Boulé
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.