Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Faster Board Representations/Move Generators

Author: Gerd Isenberg

Date: 12:29:17 02/23/06

Go up one level in this thread


On February 23, 2006 at 15:07:56, Dann Corbit wrote:

>On February 23, 2006 at 15:02:25, Christopher Conkie wrote:
>
>>On February 23, 2006 at 14:49:01, Dann Corbit wrote:
>>
>>>On February 23, 2006 at 14:47:23, Christopher Conkie wrote:
>>>
>>>>Is there a way to keep board representations entirely in hexadecimal format
>>>>until output of moves are required. How would one accomplish rotation for
>>>>diagonals without conversion. For example, is it needed to convert pieces to a
>>>>number if you started with something like.....
>>>>
>>>>typedef unsigned long long bitboard;
>>>>
>>>>bitboard B_Occ = 0xffff000000000000ULL;
>>>>bitboard W_Occ = 0x000000000000ffffULL;
>>>>
>>>>bitboard All_P = 0x00ff00000000ff00ULL;
>>>>bitboard All_N = 0x4200000000000042ULL;
>>>>bitboard All_B = 0x2400000000000024ULL;
>>>>bitboard All_R = 0x8100000000000081ULL;
>>>>bitboard All_Q = 0x1000000000000010ULL;
>>>>bitboard All_K = 0x0800000000000008ULL;
>>>>
>>>>I have been toying with this idea but am not quite sure of the validity of it's
>>>>basis. I was thinking that if less conversion took place it would improve speed
>>>>significantly.
>>>>
>>>>Any thoughts would be nice.
>>>
>>>Internally, all the numbers are binary.  If you assign them a decimal number, it
>>>gets converted to binary internal format.  It happens at compile time and so the
>>>speed difference is 0.00000%
>>>
>>>Or maybe you are joking and left out the smiley.
>>
>>Yes and no. ;-)
>>
>>Seriously I am looking at ways to improve speed without having to use arrays to
>>rotate for diagonals.
>>
>>There is a max of 7 squares in any one specific horizontal, vertical or diagonal
>>direction for a piece to move to. If we know that, why not have a table that
>>looks at each of the 8 directions and subsequent squares in turn until a
>>friendly or opposing piece is found and deal with that accordingly. This would
>>require a table that is stepped through consisting of the 56 values that shift
>>up, down or across.
>>
>>Did I explain that well enough. It is a bit bitty I know.....
>>
>>It just seems to me simpler to me to comprehend. Question is would it be
>>significantly slower or maybe even faster?
>>
>>:-)
>>
>>Christopher
>
>OK, now I see what you were after.
>
>Actually, I have done something very similar to your idea.
>You can write a program to write a program.  What the program does is to examine
>all (max of 128) possible bit combinations for a slider on a given square.  Then
>the result is a giant switch statement with integral constants.
>
>This idea is a good one and the results are very fast.
>
>You can output not only the captures and non-captures, but also the pins and
>half-pins as bit masks.  You can also know which of your own chessmen is
>defended and by what piece types they are defended.
>
>All of this can be put into a precomputed data structure.

Sounds very interesting, Dann. Can you elaborate a bit more about the idea?
Do you mean a kind of rotated lookup with 7-bit distinct white/black occupied
states?



This page took 0.02 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.