Author: Gerd Isenberg
Date: 07:20:27 01/08/04
Go up one level in this thread
On January 08, 2004 at 08:29:29, Andreas Herrmann wrote: >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 Nice sample, but why so much effort for the poor pawn on d3, if there are lot of more valuable pieces hanging around ;-) And what about X-rays, batteries and indirect defences? Gerd
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.