Author: Tony Werten
Date: 11:41:42 10/10/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
The definition of backward pawn is
1) It is not defended
2) It can not be defended by moving another pawn forward ( because a) it is
blocked or b) it will attacked by an opponent pawn )
3) When moved forward, it will be attacked by an opponent pawn before being
defended ( if at all)
I'm very interested to know how you do this with 1 AND.
Tony
PS Bitboards excel in pawnstuff. Unfortunately it completely doesn't matter
because you hash the pawnstuff anyway.
>
>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
>
>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.