Author: Gerd Isenberg
Date: 07:06:08 01/08/04
Go up one level in this thread
On January 08, 2004 at 07:56:28, Tord Romstad 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. > >You're right, but you will never need all the 2048 possible 11-bit >attack vectors. During a single search, the number of different >combinations of attack vectors that occur is usually not very big >(I think). It is possible to compute the SEE stuff on the fly and >store the results in a small hash table, instead of using your huge >48 MB table. Nice idea. I do a kind of setwise SEE on the fly in a more inaccurate way - as i have several bitboards for each side with disjoint attacks per piece type and direction - and some aggregated where the number of (xray) attacks is the property and finally whether squares are "tabu" for some piece type. Gerd > >I originally used a table almost identical to Ed's, but recently I >have switched to using a small SEE cache (the size is 2 KB). There >was no noticable slowdown. I am fairly sure a similar approach >(perhaps with a somewhat bigger cache) would also work well with >Andreas' bigger attack tables. > >Tord
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.