Fastest code

[cms271828]

Hi, haven't been here for quite a while..
Just picked up again with the SEE code I was doing last.

I use fixed shift magics now for move generation now too.
In the SEE code, when looking for attackers, say black_bishops.. I would use the fixed shift magics to get a 64 bit value for both diagonals that I AND with the black_bishops to give the attacking black bishops

Once a bishop has been processed, I only need to look down the ray it lies on, instead of repeating the whole process above.

My idea was to get the index of the black_bishop (0-63), call it BB
Then if TO is the to square, TO - BB (assume TO>BB) can be one of the following:

9,18,27,36,45,54,63 (a8-h1 direction)
7,14,21,28,35,42,49 (a1-h8 direction)
1,2,3,4,5,6,7 (rows)
8,16,24,32,40,48,56 (files)

This could come in handy, since only 7 appears twice.
So then I could work out the direction outwards from TO,
and keep going till I get a non-empty square, each time OR-ing (1<<sq) to the earlier 64 bit value found using the fixed shift magics.

Is this a good idea? I was also thinking of using magics along the ray in question, then OR it with the earlier 64-bit value found.

Any ideas/thoughts?
Thanks

[Gerd Isenberg]

Hi, haven't been here for quite a while..
Just picked up again with the SEE code I was doing last.

I use fixed shift magics now for move generation now too.
In the SEE code, when looking for attackers, say black_bishops.. I would use the fixed shift magics to get a 64 bit value for both diagonals that I AND with the black_bishops to give the attacking black bishops

Once a bishop has been processed, I only need to look down the ray it lies on, instead of repeating the whole process above.

My idea was to get the index of the black_bishop (0-63), call it BB
Then if TO is the to square, TO - BB (assume TO>BB) can be one of the following:

9,18,27,36,45,54,63 (a8-h1 direction)
7,14,21,28,35,42,49 (a1-h8 direction)
1,2,3,4,5,6,7 (rows)
8,16,24,32,40,48,56 (files)

This could come in handy, since only 7 appears twice.
So then I could work out the direction outwards from TO,
and keep going till I get a non-empty square, each time OR-ing (1<<sq) to the earlier 64 bit value found using the fixed shift magics.

Is this a good idea? I was also thinking of using magics along the ray in question, then OR it with the earlier 64-bit value found.

Any ideas/thoughts?
Thanks

I don't exactly understand what you want to approach. To prove whether you can produce the same attack bitboard from magic lookup by a nested direction/step until blocker loop?

[cms271828]

Well I use the Fixed Shift Magics to get an X shaped bitboard where I can look look for bishops or queens by doing an intersection

So suppose it intersects with 1 bishop, then I know this bishop can capture on the TO square.

But there maybe a queen lying behind the bishop
So I could remove the bishop, then use the fixed shift magics once more to create a new bitboard, which can be intersected with queens to see if one is present

But my point is.. the original bitboard will only have changed in the ray that contained the bishop, so it seems like overkill to use the fixed shift magics a second time when I could just loop through squares on that ray.

I suppose I could write both algorithms, and use the fastest (or something else), is that clearer?

Thanks

[bob]

Well I use the Fixed Shift Magics to get an X shaped bitboard where I can look look for bishops or queens by doing an intersection

So suppose it intersects with 1 bishop, then I know this bishop can capture on the TO square.

But there maybe a queen lying behind the bishop
So I could remove the bishop, then use the fixed shift magics once more to create a new bitboard, which can be intersected with queens to see if one is present

But my point is.. the original bitboard will only have changed in the ray that contained the bishop, so it seems like overkill to use the fixed shift magics a second time when I could just loop through squares on that ray.

I suppose I could write both algorithms, and use the fastest (or something else), is that clearer?

Thanks

Why not just generate that "x-shaped vector of 1's" and then AND that with a single vector originating at the source and radiating out along just one diagonal in the direction you want?

Or use my approach, which is to initialze a bitboard called "b_sliders" to contain 1's for all bishops and queens of both sides. As you "use" a piece in the swap logic, clear that bit. When you generate the 4 diagonals you mentioned using magic, just AND that with the "unused" bishops/queens and you are ready for the next iteration.

[cms271828]

Thanks, but I couldn't make sense of either of those approaches...

Approach 1.
Lets say TO square is d5(27) (a8=0, h1=63)
With a bishop on c6(18) and a queen on b7(9)

When I get the 'X' bitboard, going outwards from d5 towards a8,
the only square in 'X' will be c6(18)

So whatever I AND it with, I won't get square b7(9).
Perhaps I've misunderstood, but I'm not sure where.


Approach 2.
Similarly to above, I don't see how AND-ing the 'X' bitboard with anything can give you the valid bishops/queens further out on the diagonal in question.

Please help me to clarify, cause now I'm extra confused.
Thanks

[Gerd Isenberg]

Well I use the Fixed Shift Magics to get an X shaped bitboard where I can look look for bishops or queens by doing an intersection

So suppose it intersects with 1 bishop, then I know this bishop can capture on the TO square.

But there maybe a queen lying behind the bishop
So I could remove the bishop, then use the fixed shift magics once more to create a new bitboard, which can be intersected with queens to see if one is present

But my point is.. the original bitboard will only have changed in the ray that contained the bishop, so it seems like overkill to use the fixed shift magics a second time when I could just loop through squares on that ray.

I suppose I could write both algorithms, and use the fastest (or something else), is that clearer?

Thanks

Yes, that is clearer, thanks. I would intuitively vote for a second magic lookup for the x-ray attacks with the removed bishop...

[Desperado]

Hi Colin,

(hopefully i dont missed you point...)

problems i "SEE" ...
========================

*

lva-ordering must be handled. That means you may have to pick the "next" attacker
from another direction. This also means you have to manage (store somehow),
the current direction state, so when you execute this direction again you
will be able to "continue" correctly. In other words this makes it complicate
and produces overhead, that alone should be more costly than using again magic-attacks.

*
assuming you have a direction-list with "attackers", that are not connected,
like wQa8,bBb7,wBc6 TO(d5): how do you handle the queen ?! The known algorithms wont have
a problem with sth. like that.

*

how do you check "pseudo-attackers", lets compare two piece constellations:

a: wQa8,bBb7,wBc6 TO(d5)
b: wQa8,bRb7,wBc6 TO(d5)

if i understand your idea correctly, you will miss at least one of the two cases.
In case "a" you may miss the queen because you might stop by the first black piece as condition,
in case "b" you may add the queen because you dont stop by the first black piece as condition.

Now how do you stop looping a direction ?


So my first impression is, if you cleanup the LVA you get a new "temporary" occupancy.
This "tmpOcc" should be used to compute the "next" attacker-list with magics, for the next
iteration and so on.

Michael

[cms271828]

Ok thanks, well I've got a plan of what to do..

I will use 11 step system to find the attackers.
Ignoring pawns and knights for now, I assume there are 5 possible pieces that can take on TO..

B,R,R,Q,K (since bishops are on different coloured squares).
So each side side starts on step 1:

1: B(2) R(5) Q(8) K
2: R(3) Q(9) K
3 R(4) Q(10) K
4: Q K
5: R(6) Q(11) K
6: Q(7) K
7: B K
8: B R(10) K
9: R(10) K
10: R K
11: B R K

On step 1, if no bishop is found, it looks for a rook, if no rook is found, it looks for a queen, and if no queen, then looks for king.
Supposing it finds a bishop, then it will use step 2 to search for the next piece, and so on...

If I take gerds advice, I will use the fixed shift magics each time if needed.

The whole thing will it into an iterative alpha beta loop as oppose to recursive.

This is about the best I can think of anyway for SEE