Author: Reinhard Scharnagl
Date: 08:36:49 04/14/03
Go up one level in this thread
On April 14, 2003 at 04:47:44, Andreas Rueckert wrote: Hi! >I'm thinking about a incremental movegenerator for our little project. The idea >is to store the moves for the pieces in a array and then check the last moved >pieces, if they intersect with the potential moves of the piece on the square. >If not, the moves that were computed before the piece was moved, could be >reused. Has this been done before? (I guess so, since almost everything has been >tried in this field, as it seems to me). Within the early state of the Smirf project I had implemented a sequential move generator, which additionally generates legal moves only, each on demand. The generating always starts trying to reproduce a specified killer move. >Are there any numbers, how much performance gain is too expect from such a solution? Sorry, there are no numbers of that sort. There will be 4 million to 20 million moves be generated at an AMD Athlon 1800+. I suppose advantages will be in mating problems, because there is no need to expand final knots fully . During a normal game there seems to be a need to expand knots into all resulting moves because of the idea of move ordering. I solved this problem by filtering out classes of moves and buffering the lower estimated. Today I prefer to expand lazy but en block, because I now need a lot of information for evaluating the parent knot. I hope, for me this will be the more performant solution. Regards, Reinhard
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.