Author: KarinsDad
Date: 22:39:35 03/22/99
Go up one level in this thread
On March 23, 1999 at 00:05:52, Eugene Nalimov wrote: >On March 22, 1999 at 23:33:50, Dann Corbit wrote: > >>On March 22, 1999 at 23:19:57, KarinsDad wrote: >>>On March 22, 1999 at 22:35:03, Dann Corbit wrote: >>[snip] >>>This looks like it will work for some things. However, how do you determine if a >>>file is open or not since your bitboard is row based? >>Well, you could do 8 tests or (cough, blush) a chummy, cheesy bitwise operation >>with one of 8 64 bit integers with the appropriate column bits set, pretending >>your struct was a 64 bit integer. [Looks out the window, changes the subject]. >>A similar evil trick could be used for diagonals, if a person were to stoop to a >>similar underhanded, chummy hack. But of course, that would be in violation of >>the ANSI/ISO standards and not portable at all. [Whistles, while averting his >>eyes...] >>[snip] > >You often need not the entire file, but it's subset that >is attacked by, e.g., a rook. And here the fact that >corresponding bits are contigious helps a lot. > >Example with non-rotated bitboard: your rook is at e1. There >are 2 more pieces at the first rank - at b1 and g1. You want >to determine, what squares you rook attacks. > >The first rank in the bitboard (assuming "natural" enumeration) >is: 01001010. You use it (and location of you rook) as an index >to the rook files atacks table: rfa[e1][01001010], and it gives >you the result: 01110110. > >You could do that because there were only 256 possible variants >of piece placing in the rank, Actually, there are only 128 possible variants unless you send values such as rfa[e1][01000010] where e1 is the last location the piece was on, however, the piece is now off of the board (and 00000000 would be returned). If you do not do this (I do not know why anyone would), then you must still allocate memory for all 256 variants, even though half of them are not used (i.e. there would be no reason to check rfa[e1][01000010] since any check of a piece at e1 would always require the "e" bit be turned on). BTW, I do not return a value of 01110110 in the above example. How do you acquire the last value in the list below (this example is from my design spec modified to correspond to Eugene's lookup system), I was just wondering what you did to go from the table lookup to the desired result: 00100101 row byte from white bitboard where the 3rd bit from the left is a rook 10000010 row byte from black bitboard 10100111 row byte from white and black xored bitboard 11011100 row byte returned from Eugene's table lookup 11011000 row byte expected where the 6th bit are cleared (it is a white piece), the 7th and 8th bits are cleared (behind the white piece), but the 1st bit is still there (it is a black piece). You are using the xored bitboard for the lookup table, correct? KarinsDad > and enumeration of squares is >contigious. To do that with the rank, you need bitboard that >is rotated 90 degrees. > >Eugene
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.