Author: Robert Hyatt
Date: 13:34:08 08/20/04
Go up one level in this thread
On August 20, 2004 at 14:27:22, Tord Romstad wrote: >On August 20, 2004 at 11:22:24, Tord Romstad wrote: > >>On August 20, 2004 at 10:59:16, Robert Hyatt wrote: >> >>>On August 20, 2004 at 05:05:19, Tord Romstad wrote: >>> >>>>On August 20, 2004 at 00:37:26, Eric Oldre wrote: >>>> >>>>>On August 19, 2004 at 18:46:32, Robert Hyatt wrote: >>>>>> >>>>>> >>>>>>Has to do with passed pawns and no pieces on the board. If you form a square >>>>>>with one side going from the pawn to its promotion square, if the king is inside >>>>>>that square, the pawn can't run and promote. If the king is outside that square >>>>>>then the pawn promotes and wins. Simple idea with a few wrinkles to deal with. >>>>> >>>>>Thanks Robert, >>>>>that is actuall something I know i've read about at some point on this board. >>>>>and it's something that i hope i'll get to at some point. >>>>> >>>>>wouldn't you need to have 2 different bit boards? depending on who's turn it is >>>>>to move? >>>> >>>>You don't need even a single bitboard. Just compare the distance of the >>>>passed pawn to the promotion square to the distance of the defending king >>>>to the promotion square. Subtract 1 from the defending king's distance >>>>if it is the defender's turn to move. >>>> >>>>Tord >>>> >>> >>>Bitboards don't need any subtraction, any correction for side to move, nor even >>>the exact king square. It looks something like this: >>> >>>if (white_pawn_race[square of white pawn] & BlackKing) pawn can't run. >> >>The reason you don't need any subtraction is that you use separate >>white_pawn_race and black_pawn_race bitboards depending on the side to >>move. If you double the array sizes, you can of course eliminate the >>correction for side to move. This is completely unrelated to whether you >>use bitboards or not. >> >>Without bitboards, the code looks roughly like this: >> >>if(pawn_race[(square of white pawn)-(square of black pawn)]) >> pawn can't run >> >>No big difference compared to the bitboard version, IMHO. I doubt that >>the subtraction is much more expensive than the binary 'and' in the >>bitboard version. >> >>For simple stuff like this, it simply doesn't matter much whether you >>use bitboards or not. I personally prefer not to use bitboards for >>this, because I need less memory (a single 256-byte array is all I need). >>Just a matter of taste, I suppose. > >I was a bit too fast here. After thinking a bit more about this, I think that >using bitboards for square of pawn evaluation as explained by Bob above >is not a good idea. > >Compared to my non-bitboard method, Bob's technique consumes about 4 >times as much memory, assuming the follwing data structures: > >bitboard_t pawn_race[2][64]; /* Bitboard version, 1024 bytes */ >unsigned char pawn_race[256]; /* Non-bitboard version, 256 bytes */ No doubt. But with large L2 caches and getting larger, this disadvantage disappears. > >More importantly, the bigger array used by the bitboard approach actually >contains much _less_ information. It only tells you whether the defending >king is inside or outside the square of the pawn, and not how _far_ outside >the square of the pawn it is (i.e. the number of tempi the defending side >needs to gain in order to catch the pawn). The non-bitboard technique >does not suffer from this defect. You lost me there. In a king and pawn ending, there is little opportunity for gaining a tempi against a running pawn, except in an oddball position like the famous Reti position. But again, don't forget about blocked paths to the destination. Bitmaps can handle that quickly and see that the king is "in the square" but "can't get there in time still.." > >Information density is often mentioned as an important advantage of >using bitboards. Seen in this light, the bitboard-based square of pawn >eval mentioned above is a poor way to use bitboards. The information >density in the non-bitboard version is higher by an order of magnitude. I disagree. The bitmap says "here are the squares the opposing king must be on to prevent this pawn from running." As opposed to having to compute two distances (rank and file), choosing the larger, and then comparing... > >I like Gerd's bitboard approach better, though. > >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.