Author: Gerd Isenberg
Date: 09:19:53 08/04/03
Go up one level in this thread
On August 04, 2003 at 11:05:19, Robert Hyatt wrote: >On August 04, 2003 at 06:11:20, Gerd Isenberg wrote: > >>Hi all, >> >>One common search/evaluation test is to compare the search of a position with >>it's mirrored position. >> >>There is one principle problem related to bitboard traversal in move-generation. >> >>Black pieces and targets are traversed in an other order than the "mirrored" >>pieces and targets, regardless if one uses bsf or bsr and the square-bitindex >>mapping. > >If I want to do a search, I use two commands inside crafty, "flip" and "flop". >One mirrors the board and swaps colors so that the first rank becomes the >eighth rank and so forth. I also reflect the board so that the A-file >becomes the H-file and so forth. Now the order is the same. Hi Bob, I have also implemented these commands for test purposes. I guess "Flop" makes only sense if no more castling is possible, specially in testing endgames. Here i even use some "File-rotate" commands. > >For asymmetry in the evaluation, I flip and print, flop and pring, and >flip/flop and print. The scores must match. If they don't, traces of >the evaluation make for interesting comparing for the reason you gave, >of course. > > I see, but if you search these positions from the root, you may get different solution times, because move generation of the flipped position may slightly differ due to the "assymetrical" bitscan behaviour. I like to get an absolute deterministic and equal search behaviour for flipped and none flipped positions - at least in a kind of conditional compiled debug-version. Gerd > > > >> >>Lets take some white pawns with following bit indicies: b2(9),d2(11) and c3(18). >>With bsf you'll find them in ascending order: b2,d2,c3. Now with "mirrored" >>black pawns on b7(49),d7(51),c6(42) we will foreward scan the ascending c6,b7,d7 >>squares. >> >>Even if there is further move sorting, the different initial order of generated >>moves in mirrored positions implies different search trees - and therefore >>slightly different search results. >> >>How do you deal with this behaviour in your bitboard based program? >>I ignore it so far. >> >>One possible solution with x86-64 is to use the fast "bswap reg64" instruction >>(direct path,1 cycle) before scanning black pieces or targets for movegen. >>"bswap" mirrors the bits rankwise (8 becomes 1, 7 become 2...) and a remirror of >>the scanned bit index is a simple xor with 0x38. >> >>According to the sample above we mirror the black b7,d7,c6 pawns to b2',d2',c3' >>and we get the same order as with original white pawns: b7,d7,c6. >> >>One drawback is of course the need of a color2move paramter for bitScan - or >>separate black/white traversal. >> >>Any remarks or implementaion hints? >> >>Regards, >>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.