Scrambling squares for magic bitboard?

[stegemma]

First of all: I don't use magic bitboards at present, so maybe I'm writing something useless. Reading about magic bitboards, I have had a strange idea: how about to "scramble" all chessboard squares, before to compute moves with magic? Normally we take bits in order this way or similar:

Code: Select all

a8 b8 c8 d8 e8...f1 g1 h1

but if we "scramble" casually or with some logic all the bits, we can have this situation:

Code: Select all

d6 c4 f7 b1...f2 a7

In this situation maybe we can find a better uniform distribution of moves on such kind of scrambled chessboard and no difference between finding rook moves and bishop moves.

[elcabesa]

I'm not an expert of magic bitboard, but I think that the gain of it is to get the move list in a very fast way respect to other methods.
If you find a fast way to remap the squares as you proposed it could make sense.. If you need to iterate over the result to convert it doesn't make sense.
This is my understanding of it.

ciao

[stegemma]

I'm not an expert of magic bitboard, but I think that the gain of it is to get the move list in a very fast way respect to other methods.
If you find a fast way to remap the squares as you proposed it could make sense.. If you need to iterate over the result to convert it doesn't make sense.
This is my understanding of it.

ciao

I agree with you but why one need to convert forth and back? For humans is more easy to see a rook moving on a line but for an engine see a piece moving "by jumps" is not a problem. So you can map the chessboard to 64 bit in scrambled order at start and convert only the result. One way could be something like knight jump scrambling but other schemas could be good. Maybe pure random scrambling was not a good idea but using a schema could be.

[elcabesa]

Current square allocations in bitboards has some good property,you can for example do some operation with bitwise operations. Losing those benefit will reduce bitboard benefits. You obviously have to rewrite from the foundation your engine

[stegemma]

Current square allocations in bitboards has some good property,you can for example do some operation with bitwise operations. Losing those benefit will reduce bitboard benefits. You obviously have to rewrite from the foundation your engine

Of course it requires a huge rewrite of the code but could be interesting for new engines. You don't lose the facility of bitwise operations because, in fact, it is just a different way to view the chessboard. For sample, if "scrambling" would be just shifting by one bit, all vertical rook moves becomes bishop moves (and a8 moves to actual h1).

[Henk]

Probably implementing magic bitboard in Skipper was a waste of time. But I don't know. I already forgot how it worked. I also don't remember what I used before. Bit boards are fine for 64 squares.

[AlvaroBegue]

Current square allocations in bitboards has some good property,you can for example do some operation with bitwise operations. Losing those benefit will reduce bitboard benefits. You obviously have to rewrite from the foundation your engine

Of course it requires a huge rewrite of the code but could be interesting for new engines. You don't lose the facility of bitwise operations because, in fact, it is just a different way to view the chessboard. For sample, if "scrambling" would be just shifting by one bit, all vertical rook moves becomes bishop moves (and a8 moves to actual h1).

I do a lot of useful operations with bitboards that would be broken by scrambling. I have functions N, S, W, E (North, South, West, East) so I can quickly figuring out things like what squares are defended by a white pawn (N(W(wps)|E(wps)), or what pawns can move forward (wps&S(empty)). You can't improve magic bitboards enough to compensate for the pain introduced by the scrambling.

[JVMerlino]

Probably implementing magic bitboard in Skipper was a waste of time. But I don't know. I already forgot how it worked. I also don't remember what I used before. Bit boards are fine for 64 squares.

Or you could just go here and download Pradu's "magicmoves", which is extremely easy to implement....
http://pradu.us/old/Nov27_2008/Buzz/

[abulmo2]

Your approach reminds me of the rotated-bitboards. Move generation was close to magic-bitboards, but updating/restoring the board was more cumbersome, and overall the code was more complex. I am afraid your scrambled-bitboards will suffer from the same defects.

[stegemma]

Your approach reminds me of the rotated-bitboards. Move generation was close to magic-bitboards, but updating/restoring the board was more cumbersome, and overall the code was more complex. I am afraid your scrambled-bitboards will suffer from the same defects.

I just shared an idea but maybe it could be used for perft or could be an hint for other different approach.