Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Thoughts about board representations...

Author: Dan Newman

Date: 00:02:31 02/12/00

Go up one level in this thread


On February 12, 2000 at 00:32:51, Bruce Moreland wrote:

>On February 10, 2000 at 17:34:52, Tom Kerrigan wrote:
>
>>There seems to be a huge pro-bitboard movement underway... But for those of us
>>not jumping on the bandwagon, I have some thoughts.
>>
>>Let's say you have an array to represent the board:
>>int board[64];
>>
>>If you make white pieces positive (i.e., pawn = 1, knight = 2) and black pieces
>>negative, you can use the following macros:
>>
>>#define COLOR(x)  (x < 0)
>>#define TYPE(x)   (x < 0 ? -x: x)
>>
>>I don't like the TYPE macro because it has a branch. So let's say you set bit #4
>>if the piece is black. Then you can use these macros:
>>
>>#define COLOR(x)  (x >> 3)
>>#define TYPE(x)   (x & 7)
>>
>>This seems pretty good, but I still have a minor complaint: a pawn = 1, so all
>>the arrays that are indexed by piece type have to have an unused element at the
>>beginning.
>>
>>You can set the pawn = 0, but then the empty square value has to be non-zero. On
>>some proessors, this increases the time it takes to see if a square is empty.
>>
>>If you're using the 0x88 trick, you get two boards to play with, so the color of
>>the piece on square x can be board[x] and the piece type can be board[x+8]. I
>>think this is a pretty good solution, but it involves some extra memory
>>accesses, not only when you're examining the board, but also when you're moving
>>pieces around.
>>
>>If you have a piece struct, your board can be pointers to the structs:
>>piece_struct *board[64];
>>
>>Then the color of the piece on square x is board[x]->color and the piece type is
>>board[x]->type. I think this solution is pretty cool, but it involves some extra
>>memory accesses. Plus, every time you want to check the piece type of square x,
>>you have to make sure that board[x] isn't NULL. That's not cool.
>>
>>So... each method has its minor advantages and disadvantages. I can't really
>>decide which I like more. What do other programmers do? Is there some really
>>elegant solution that I'm missing? I hope so. :)
>>
>>-Tom
>
>I don't think it matters what you do, and starting out with intent to save a few
>cycles is like being extremely concerned about making sure that the first step
>you take on the way to work each morning is absolutely perfect.
>
>bruce

Yeah, but I always have to pound my head against a brick wall to figure things
like that out :).  (I seem to have a compulsion to fiddle and tweek code--just
to get that extra 1%--and have continued to do so even after I figured out what
you said above...)

-Dan.



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.