Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Design choices in Crafty

Author: Robert Hyatt

Date: 17:08:46 06/24/04

Go up one level in this thread


On June 24, 2004 at 19:35:34, Russell Reagan wrote:

>On June 24, 2004 at 16:25:58, Robert Hyatt wrote:
>
>>The only bad part of the if (wtm) { } else { } type of coding is, as you
>>mentioned, duplication.  And yes, it leads to errors.  However, in Cray Blitz
>>where I didn't do this I _also_ had my fair share of bugs caused by trying to do
>>things like "is this rook on the 7th rank?" and the test not working for both
>>sides, or things like "is this pushing a passer to the 7th?" and then later
>>changing that to 6th/7th and the change not working for one side.  So probably
>>there will be bugs no matter which approach you use.  And the lack of "tests"
>>makes what I do at least pretty easy to read...
>
>Out of curiosity, what kind of problems did you have with, "is this rook on the
>7th rank?" and "is this pushing a passer to the 7th?"? My guess is you did
>something like this...
>
>// A little code to setup the situation...
>enum { white, black };
>int side;          // side to move, white or black
>Bitboard rooks[2]; // rook bitboards, one for each color
>
>// The test...
>if (rooks[side] & rank_7_mask) { ... }
>// ERROR! ------> ^^^^^^^^^^^
>
>And instead, you should have done something like this?
>
>// A little setup code...
>Bitboard pre_promotion_rank_mask[2] = { rank_7_mask, rank_2_mask };

I usually used some math to avoid a lookup in a memory table, which can be slow.
 And the problem really showed up when I first wrote something like "is this a
pawn push to the 7th?" and then later modified it to be "6th or 7th" without
thinking about it now has to be 2 or 3 for black.




>
>// The test...
>if (rooks[side] & pre_promotion_rank_mask[side]) { ... }
>
>Okay, there is probably a better (and shorter) name than
>'pre_promotion_rank_mask', but you get the idea :)
>
>Do you think this way is a good way of writing code to generically handle
>bitboards? Or would you do it another way?

I haven't really given it much thought.  Interspersing code for both sides is
usually far worse than separating it into "blocks".  IE I originally had it
written in your "clean" approach in Cray Blitz, but Harry Nelson whacked it up
into what was very similar to the crafty approach, because of how instruction
buffers work on the Cray.  The duplication is a pain.  Non-duplication causes
other kinds of pain.  So I have generally stuck with what I already have since
it works. :)




>
>I guess one improvement would be to wrap the thing up in a function, so we can
>try several versions and see which works the best, but this is the general idea,
>correct?
>
>Bitboard PrePromotionRankMask (int color)
>{
>    assert((color == white) || (color == black));
>    static Bitboard mask[2] = { rank_7_mask, rank_2_mask };
>    return mask[color];
>}
>
>Bitboard PrePromotionRankMask (int color)
>{
>    switch (color)
>    {
>        case white: return rank_7_mask;
>        case black: return rank_2_mask;
>        default: return (Bitboard)0;
>    }
>}
>
>Bitboard PrePromotionRankMask (int color)
>{
>    assert((color == white0 || (color == black));
>    return 0x00ff000000000000 >> (color * 48);
>}



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.