Author: Robert Hyatt
Date: 07:33:24 02/01/01
Go up one level in this thread
On February 01, 2001 at 08:13:18, Severi Salminen wrote: >>you need one more test. How quickly can you generate _only_ capture >>moves? That is the biggest part of the total move generation process, >>because of the q-search. And that is a place where bitmaps really shines >>brightly. IE I can generate captures _just_ as quickly as I can generate >>non-captures. I don't have to cull non-captures or anything, after the >>fact... I just never generate them in the first place... > >I didn't quite follow. I don't understand the word "cull" - I don't have a >dictionary available right now... cull means to "throw out". IE a normal move generator will either (a) generate all moves and then cull or throw out non-captures; (b) have a special move generator that loops to generate moves and each time the target square is empty, the move is not produced. But it takes time to loop over the empty squares. > And what do you mean by "I can generate >captures _just_ as quickly as I can generate non-captures"? Are you doing both >in the same function, I assume not? I have two functions. One starts with the valid set of target squares as all empty squares. That generates all moves that are non-captures. The second function starts with the valid set of target squares as the squares occupied by opponent pieces, which generates only captures. With bitmaps, if a piece can move to 12 non-capturing squares, I loop exactly 12 times. If the same piece can capture only one piece, I loop exactly once to generate the captures... I don't look at empty squares, I don't notice empty squares, etc. > I have two functions : gen_captures and >gen_non_captures. Of cource gen_captures is the the one which should be fast and >I can generate them separately. But this test still gives you some figure on >how fast you generate moves - captures or non-captures. It may indeed be that >one could make capture generation faster and same time affecting non-capture >generation (is this what you meant). In that case this test gives "wrong" >result. > >Severi That is the idea. IE in my q-search, I want _only_ captures, and I get those very efficiently. In my normal search, assuming that either the hash move didn't produce a cutoff, or there was no hash move to consider, I also want only captures as often a single capture is all you need to produce a beta cutoff. I simply think that the ability to generate moves to a specific set of squares, which might be the squares with enemy pieces, or the squares between an enemy sliding piece and my king when I am in check, is a plus. When you need _all_ moves, it takes two function calls in Crafty to get them. That is a small penalty. When you need just captures, it is not only very efficient but the second function call is eliminated as is all the work of scanning over empty squares to find a piece to capture... I wouldn't say the advantage is huge at all. But it is there.
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.