Author: James Swafford
Date: 11:05:22 12/01/04
Go up one level in this thread
On December 01, 2004 at 13:35:56, Anthony Cozzie wrote: >On December 01, 2004 at 08:19:55, James Swafford wrote: > >>On December 01, 2004 at 01:20:17, Tony Werten wrote: >> >>>On November 30, 2004 at 15:44:47, James Swafford wrote: >>> >>>>On November 30, 2004 at 14:59:04, Dan Honeycutt wrote: >>>> >>>>>On November 30, 2004 at 13:42:39, Dann Corbit wrote: >>>>> >>>>>>On November 30, 2004 at 13:25:08, James Swafford wrote: >>>>>> >>>>>>>On November 30, 2004 at 12:51:38, Andrew N. Hunt wrote: >>>>>>> >>>>>>>>Hi! >>>>>>>> >>>>>>>>I've recently implemented bitboards (standard and rotated) and have a question >>>>>>>>about pre-computing moves which contain blocked squares. Let's say I have the >>>>>>>>occupied rank: >>>>>>>> >>>>>>>>bQ, wN, _, wR, _, bP, bN, _ >>>>>>>> >>>>>>>>and I want to find the valid moves for the white Rook. How do I handle modifying >>>>>>>>its bitboard rank: 11010110 to remove the blocked squares and only store the >>>>>>>>available squares: 01101100? (which I can then And with the white/black pieces >>>>>>>>to find valid Rook moves) >>>>>>>> >>>>>>>>Maybe I'm missing something obvious... :-? >>>>>>> >>>>>>>You need to precompute a two dimension array >>>>>>>Bitboard rank_moves[64][256]. The first index is the square >>>>>>>the rook is on. The second index is the state of the rank >>>>>>>(in this case 11010110 base 2). >>>>>>> >>>>>>>You'll need a similar array for files and diagonals >>>>>>>(one for the a1->h8 direction and one more for the h1->a8 >>>>>>>direction). >>>>>>> >>>>>>>Just build these arrays in your program initialization >>>>>>>by doing some looping. >>>>>> >>>>>>You can get by with 128 entries instead of 256 in most cases, because a piece >>>>>>never attacks or defends the square it is standing on. >>>>> >>>>>I use [64][128] by simply throwing away the h file. I could use [64][64] by >>>>>likewise throwing away the a file but it would cost me an extra add for my shift >>>>>(ie I'd have to shift by 8*(rank-1) + 1 instead of 8*(rank-1)). Getting rid of >>>>>the square the piece is on could, I guess, get you to [64][32] but looks like it >>>>>would also require some extra math. >>>> >>>>I don't think you could get to 32. What if the square you're on >>>>is in the A or H file? >>> >>>32 >>> >>>Might be better to change the declaration to [33][64] for easier >>>indexcalculation. >> >>I don't see it. >> >>I'f I'm on the A1, I could potentially travel (on this rank) >>to B1->H1, depending on the occupancy of those squares. >>The set of squares I can travel to doesn't depend on H1 >>(if we ignore captures of own pieces). >> >>So, I care about the occupancy of B1->G1 = 6 squares = >>2^6 states = 64. >> >>Would you further explain how to reduce this to 32? > >Because you have the order wrong. > >anthony Huh? Order of what? Are we talking about the same index? We were originally discussing rank_moves[square][state_of_rank]. Dan H. stated he uses a 7 bit state_of_rank, that he could use a 6 bit state_of_rank, then suggested reducing it to 5 bits. I questioned that (still do). Tony said: <quote> 32 Might be better to change the declaration to [33][64] for easier indexcalculation. </quote> ????? I don't know what that means. Is he saying you _can_ reduce the state_of_rank to 5 bits? (And if so, how?) Or- is he saying state_of_rank is 6 bits, but that num_squares can be reduced to 33? (And again, how?) -- James
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.