TalkChess.com

Posted: **Sat Dec 20, 2014 9:20 am**

It is well known that bsf (bitscan forward) and bsr (bitscan reverse) dont behave
symmetrical for white/black move generation using bitboards.

This can be circumvented by the following:

Code: Select all

const int MirrorTable&#91;2&#93;&#91;64&#93; = &#123;
	&#123;
		 0, 1, 2, 3, 4, 5, 6, 7,
		 8, 9,10,11,12,13,14,15,
		16,17,18,19,20,21,22,23,
		24,25,26,27,28,29,30,31,
		32,33,34,35,36,37,38,39,
		40,41,42,43,44,45,46,47,
		48,49,50,51,52,53,54,55,
		56,57,58,59,60,61,62,63,
	&#125;,&#123;
		56,57,58,59,60,61,62,63,
		48,49,50,51,52,53,54,55,
		40,41,42,43,44,45,46,47,
		32,33,34,35,36,37,38,39,
		24,25,26,27,28,29,30,31,
		16,17,18,19,20,21,22,23,
		 8, 9,10,11,12,13,14,15,
		 0, 1, 2, 3, 4, 5, 6, 7,
	&#125;
&#125;;

inline int FirstOneSym&#40;int wtm, U64 A&#41;
&#123;
	int sqr&#91;2&#93;;
	sqr&#91;0&#93; = FirstOne&#40;A&#41;;
	sqr&#91;1&#93; = FirstOne&#40;bswap&#40;A&#41;);
	return MirrorTable&#91;wtm&#93;&#91;sqr&#91;wtm&#93;&#93;;
&#125;
inline int LastOneSym&#40;int wtm, U64 A&#41;
&#123;
	int sqr&#91;2&#93;;
	sqr&#91;0&#93; = LastOne&#40;A&#41;;
	sqr&#91;1&#93; = LastOne&#40;bswap&#40;A&#41;);
	return MirrorTable&#91;wtm&#93;&#91;sqr&#91;wtm&#93;&#93;;
&#125;

One nice side effect is that the usual:

Code: Select all

fr = tr->wtm ? LastOne&#40;Pcs&#41; &#58; FirstOne&#40;Pcs&#41;;
to = tr->wtm ? FirstOne&#40;Atk&#41; &#58; LastOne&#40;Atk&#41;;

can be replaced with

Code: Select all

fr = LastOneSym&#40;tr->wtm,Pcs&#41;;
to = FirstOneSym&#40;tr->wtm,Atk&#41;;

which drops the condition.

My own tests show that this is slightly slower than the old code.

Regards, Lasse

Posted: **Sat Dec 20, 2014 10:45 am**

Lasse Hansen wrote:It is well known that bsf (bitscan forward) and bsr (bitscan reverse) dont behave
symmetrical for white/black move generation using bitboards.

What do you mean? Gcc intrinsics __builtin_ctz and __builtin_clz are symmetric.

Posted: **Sat Dec 20, 2014 10:55 am**

To create a quite color independent set of chess routines you have to achieve an identical behavior for color-swapped positions. If routines would have different time consumptions e.g. when detecting check threats or performing moves or removes, symmetry will be broken. Thus when calculating something for the active player, there a view must be provided not being distinguishable from those having everything swapped: north/south, black/white and side-to-move.

Moreover this has to be true also for any used zobrist key while caching is used.

Posted: **Sat Dec 20, 2014 11:05 am**

I didnt mean the functions themselves, but the move generation for black/white side when one want to generate moves farthest away first.

In my movgen I take the piece closest to 'own' side and moves it as close as possible to the opponent side with:

Code: Select all

fr = tr->wtm ? LastOne&#40;Pcs&#41; &#58; FirstOne&#40;Pcs&#41;;
to = tr->wtm ? FirstOne&#40;Atk&#41; &#58; LastOne&#40;Atk&#41;;

For starting position this then gives:
Black first knight move is Ng8-f6
White first knight move is Nb1-c3
which is not symmetrical.

The new functions get this behavior symmetrical.
(assuming square mapping is A1, B1,. or H8, G8,... etc)

Regards, Lasse

Posted: **Sat Dec 20, 2014 11:09 am**

Rein Halbersma wrote:
Lasse Hansen wrote:It is well known that bsf (bitscan forward) and bsr (bitscan reverse) dont behave
symmetrical for white/black move generation using bitboards.
What do you mean? Gcc intrinsics __builtin_ctz and __builtin_clz are symmetric.

Lasse means:
Scanning White in a1..h1, a2 h2,,,..h8 order
Scanning Black in a8..h8, a7 h7,,,..h1 order

Posted: **Sat Dec 20, 2014 11:10 am**

Nice. My proposal takes one extra register and xor inside the serialization bsf loop body. flipVertical = bswap.

Posted: **Sat Dec 20, 2014 10:16 pm**

Gerd Isenberg wrote:
Rein Halbersma wrote:
Lasse Hansen wrote:It is well known that bsf (bitscan forward) and bsr (bitscan reverse) dont behave
symmetrical for white/black move generation using bitboards.
What do you mean? Gcc intrinsics __builtin_ctz and __builtin_clz are symmetric.
Lasse means:
Scanning White in a1..h1, a2 h2,,,..h8 order
Scanning Black in a8..h8, a7 h7,,,..h1 order

ah my bad! I forgot that the inital position is not symmetric (I'm a draughts programmer, there everything is symmetric)

Posted: **Sun Dec 21, 2014 2:37 am**

Is the table lookup really necessary? Can't you just xor it with 56 or something along those lines?

Edit: Gerd beat me to it. I should have read the replies first!

Edit: if you want to stick with the table, try it with a "const unsigned char" array instead of "const int" (so table uses up fewer lines of L1 cache).

TalkChess.com

Symmetric move generation using bitboards

Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards

Re: Symmetric move generation using bitboards