Author: Gerd Isenberg
Date: 10:23:11 10/09/03
Go up one level in this thread
On October 09, 2003 at 09:34:00, Robert Hyatt wrote:
>On October 08, 2003 at 19:29:05, Omid David Tabibi wrote:
>
>>On October 08, 2003 at 09:51:01, Robert Hyatt wrote:
>>
>>>On October 08, 2003 at 06:33:00, Sune Fischer wrote:
>>>
>>>>On October 07, 2003 at 20:19:00, Russell Reagan wrote:
>>>>
>>>>>>I'm sure you could make use of that 8x8 array to implement non-bitboard
>>>>>>functions where appropriate and use the bitboard ones where they're more
>>>>>>convenient, taking advantage of both approaches; I don't know why this has to be
>>>>>>regarded as a dichotomy!
>>>>>
>>>>>Unfortunately many of the advantages of 0x88-like systems cannot be taken
>>>>>advantage of using a 64-element array.
>>>>
>>>>What are the many advantages of 0x88-like systems?
>>>
>>>The most important are "is square xxx on the same diagonal as square yyy"
>>>along with "is square xxx off the edge of the real board?"
>>>
>>>There are similar questions easier to answer with bitboards.
>>
>>I use a simple board[64] representation. No bitboard, no 0x88... If you have a
>>handy attack table, the board representation is insignificant. When using
>>bitboard, you get the attack table built-in, using other methods you have to
>>write your own attack table (I use 32 bit per square).
>>
>>In a simple board[64], you can check a square's diagonal by:
>>
>>#define DIAG1(x) (((x) >> 3) + ((x) & 7)) // y = x diag
>>#define DIAG2(x) (((x) >> 3) + (((x) & 7) ^ 7)) // y = -x diag
>>
>>But I don't use the above anymore. Attack tables give the needed data.
>>
>>And checking whether a square is off the edge of the board can be very easy
>>using a "mailbox":
>>
>>const int mailbox[] = {
>> -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
>> -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
>> -1, 0, 1, 2, 3, 4, 5, 6, 7, -1,
>> -1, 8, 9, 10, 11, 12, 13, 14, 15, -1,
>> -1, 16, 17, 18, 19, 20, 21, 22, 23, -1,
>> -1, 24, 25, 26, 27, 28, 29, 30, 31, -1,
>> -1, 32, 33, 34, 35, 36, 37, 38, 39, -1,
>> -1, 40, 41, 42, 43, 44, 45, 46, 47, -1,
>> -1, 48, 49, 50, 51, 52, 53, 54, 55, -1,
>> -1, 56, 57, 58, 59, 60, 61, 62, 63, -1,
>> -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
>> -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
>>};
>>
>>And address the above table using:
>>
>>const int mailbox64[64] = {
>> 21, 22, 23, 24, 25, 26, 27, 28,
>> 31, 32, 33, 34, 35, 36, 37, 38,
>> 41, 42, 43, 44, 45, 46, 47, 48,
>> 51, 52, 53, 54, 55, 56, 57, 58,
>> 61, 62, 63, 64, 65, 66, 67, 68,
>> 71, 72, 73, 74, 75, 76, 77, 78,
>> 81, 82, 83, 84, 85, 86, 87, 88,
>> 91, 92, 93, 94, 95, 96, 97, 98,
>>};
>>
>>Using bitboards is a matter of taste. I personally don't like bitboards because
>>it is not easy to extract the data you need for the evaluation function. Of
>>course people like you and Gerd who "think bitboard" can find nice tricks to
>>handle those issues, but still extracting data out of board[64], color[64] is
>>easier :)
>>\
>
>Questions:
>
>1. Is this pawn passed? bitboard == 1 AND.
>
>2. Is this pawn backward? same
>
>3. Can king stop pawn from promoting? Same
>
>4. Is file open? same
>
>5. Is file half-open? same
>
>6. is diagonal open? same
>
>7. is square weak (can never be defended by pawn again)? same
Yes, and that set-wise with previous up- and down-fills of the pawns and their
disjoint and "combined" right/left attacks sets. Even to get a set of isolated
pawns is only one "and" of all pawns of one color with the set of all files with
no own pawn attacks. Instead of the doubled or tripled pawns on one file, i use
sets of pawns which have pawns in front and/or behind the same file.
>
>The main problem in bitboards is not if something can be done, it is
>all about how to do it efficiently. One AND operation for any of the
>above is pretty cheap compared to either (a) asking the same question
>at an endpoint or (b) incrementally updating the info so that it is easy
>to ask at endpoints. There are hundreds of other questions that are just
>as easy to answer with bitboards. I haven't found anything that was easier
>with 0x88 or another representation, so far, including even SEE.
>
>
>>
>>>
>>>
>>>>
>>>>>>Anyway, why don't you use your engines to prove yourself right by getting them
>>>>>>to play better than the others? After all it's that's the aim, isn't it?
>>>>>
>>>>>Because board representation has little to do with playing strength among top
>>>>>engines, and nothing is proven if a bitboard engine beats all others.
>>>>
>>>>Yes, I think it has little to do with playing strength at any level.
>>>>It might have some to do with programming strategy and philosophy though.
>>>>
>>>>-S.
>>>
>>>
>>>Nah, vincent has already proven that if you have the fastest move generator,
>>>you _definitely_ have the best chess engine. There is no other measure of
>>>importance.
>>>
>>>:)
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.