Author: Robert Hyatt
Date: 15:08:01 05/07/98
Go up one level in this thread
On May 07, 1998 at 15:51:16, Bas Hamstra wrote: >Do you think it would be possible to generate moves incrementally? Most >of the legal moves remain the same after a move is made, it seems. I >think it might be possible to generate only moves for the pieces that >are "affected" by the prior move. > >If I'm not mistaken KnightCap does this (or was in another program?). It >has a board representation in which each square is a 32 bit number, each >bit representing the (uniquely identified) piece by which that square is >attacked. There can be no more pieces on the board than 32. > >Suppose a move a2-a3 is made. Adjust the board (="attackmap") for the >new squares a3 attacks and delete the a2-attacks. If a2 OR a3 is >attacked by a piece (of both colors) only the moves for those pieces are >to be regenerated and the board has to be updated again, for just those >pieces. > >Would that work you think? > >Problem: what to do with unmake? Compute it all "back" seems exspensive. >Or no unmake at all and fetch the previous board? Wouldnt that be >expensive too on a PC (bandwitdh and all)? > >Could someone please react on this thoughts? Early versions of Crafty used exactly this approach. But the problem is, that the incremental updates are quite costly, overall. And as anyone working on a chess engine knows, the major principle is "procrastination", never do now what you can put off for later, because if you can delay doing it, a cutoff might mean you never have to do it. As a result, the older incremental updating (my approach using bitmaps) was tossed out in favor of the rotated bitmaps, which does a little more work when you need the moves, but it does less when you don't need them...
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.