Author: Tord Romstad
Date: 03:25:54 10/09/03
Go up one level in this thread
On October 08, 2003 at 16:36:48, Robert Hyatt wrote: >On October 08, 2003 at 15:01:55, Tord Romstad wrote: >> >>People keeps claiming that, but all the bitboard code I have seen includes >>lots of loops (mostly loops through all the 1s in a bitboard). >> > >The point is this. (for loops). A bishop is on e4. It attacks a piece >at h7 and at c6. All other diagonal squares are empty. A bitboard program >that is generating captures (which is by far the most common case due to >the q-search) will go through a loop, but only _two_ iterations, one for >each capture. What about a program that doesn't use bitmaps? You will have to >traverse each diagonal until the end or hitting a blocker, in all 4 directions. > >So yes, both do loops, but one does _way_ fewer iterations. That is the >savings. But this advantage disappears when you are interested in *all* squares a piece attacks, not just the squares which happen to contain enemy pieces. In my evaluation function, I am almost always interested in doing operations for all the attacked squares. Generating captures without too many loops is not a problem for me anyway. My evaluation function does almost all the work. It does not just return a value, but also produces an ordered list of the hanging pieces for both sides, and the pieces which attack them (this information is used in the evaluation, move ordering, and for pruning and extension decisions). If I wanted, I could easily write an incremental capture generator which produced just one capture at the time (with reasonably good ordering), without having to loop through a lot of squares. So far I haven't bothered to do this, because my program spends just a tiny fraction of its time on generating captures. Tord
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.