Author: Andreas Herrmann
Date: 05:29:29 01/08/04
Go up one level in this thread
On January 08, 2004 at 07:25:19, Andreas Herrmann wrote: >On January 08, 2004 at 05:17:48, Gerd Isenberg wrote: > >>On January 07, 2004 at 14:25:48, Andreas Herrmann wrote: >> >>>Hi Ed, >>> >>>i'm just reading in your Rebel internals about your attack tables, they are >>>totally diffrent than mine, but i like your structure. >>>But how do you handle more than 1 attacker from the same kind? It seems that >>>this is not possible in your structure, or have i overread something? >>> >>>What about the following, if using a 16 bit integer: >>>Bit 1 to 3: total number of attackers >>>Bit 4 to 5: number of attacking pawns >>>Bit 6 to 7: number of attacking bishops and knights >>>Bit 8 to 9: number of attacking rooks >>>Bit 10 to 11: number of attacking queens >>>Bit 12 to 16: free for other stuff >>> >>>Ok this needs more time to fill, and the calculating of hanging pieces needs a >>>much bigger array, which gives me a result back, but i could handle all kinds of >>>attackings. >>> >>>thanks in advance for your answer >>>Andreas >> >>Hi Andreas, >> >>it's a tradeoff between space and accuracy. Ed's byte values allow a fast table >>lookup whether a piece is enprise or hanging or whether a square is safe to >>enter with some piece for one side: >> >>get_next_piece_on_the_board // scan the board >>// get status via the bits >>status = TABLE [piece_type] [WB[square]] [BB[square]]; >>if (status == 0) continue; // piece safe -> next square >>else: piece hangs, status contains its value // Q=9 R=5 B=3 N=3 P=1 >> >>char TABLE [12] [256] [256]; // about 860 Kb >> >>If you use a more accurate 11-bit word, the table size becomes >>2**6 = 64 times bigger: >> >>char TABLE [12] [2048] [2048]; // about 48 Mb >> >>I guess that huge lookup-table don't pays off. >> >>Cheers, >>Gerd > >Hi Gerd, > >yes you are right, i have written that also in my first posting. On the other >hand you don't need the total 11 bit to calculate the hanging pieces, because >bit 1 to 3 are more or less unnecessary for calculating the hanging pieces. The >total count of attackers is also included in the other bits, in nearby most of >the cases (see lowest table). >So with 8 bits the following table would be enough: >char TABLE [12] [256] [256] >Just compare bits 4 to 11 (16) from the attack tables with the above result char >table. > >And in my above structure i would have only a very few cases, where attacking >pieces could not be coded: > >Max. attackers to the same square: > max. codable theoretical max. on board > in table before promotion after promotion >--------------------------------------------------------------- >pawns 3 2 2 >knight/bishops 3 3 11* >rooks 3 2 4* >queens 3 1 8* > >* but this cases would be extremly rare or will happen in a real game nearby >never. > >Ok the disadvantage of my above structure would be the slower speed. In Ed's >case he needs just an OR to add an attacking piece. And for calculating the >hanging pieces i would need in my structure a bitshifting (?). >Well i will have some more thoughts about it. >I want to change my simple attack tables in the future, where i can't figure out >the hanging pieces. But i don't want to just copy Ed's structure. > >Thanks for your answer, and hope i will meet you in Paderborn, if nothing >happens until then (Job?). > >best wishes >Andreas just composed a funny position with a maximum of attackers to a very poor pawn on d3. Ok it's not realistic for a real game: [d]1n6/2knqrrb/bppp1q2/2N1NB2/1N3N2/1R1p1Q2/1N3N2/KBNRNB2 w - - 0 1 Andreas
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.