Author: Robert Hyatt
Date: 17:03:49 10/10/03
Go up one level in this thread
On October 09, 2003 at 13:23:11, Gerd Isenberg wrote:
>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.
>
>
Many ignore the "set" concept here. Yet it is both intuitive and
obvious after you think about it... It's the very idea that makes
bitmaps useful, IMHO.
>>
>>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.