Author: Robert Hyatt
Date: 17:02:08 10/10/03
Go up one level in this thread
On October 10, 2003 at 14:41:42, Tony Werten 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
>
>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.
I have a bitmap that I compute at the start of EvaluatePawns() that tells
me every square that _can_ be reached by a white pawn, and another for black
pawns. I use this for all sorts of stuff, including this particular term.
If I have a pawn, I use a mask for the two "supporting" squares and AND
that with the set of squares reachable by all white pawns. non-zero means
it is not backward. 0 means it is... :)
condition three takes another AND to see if the pawn can safely advance to
any square where a "supporting" square is (or can be) reached by a friendly
pawn.
I don't exactly do condition three here however, as it is evaluated as another
type of problem (I simply call that a "weak pawn" rather than a backward pawn.
IE in Crafty backward means "can't move and not defended." Weak means "can't
reach a safe square without being lost first.
>
>Tony
>
>PS Bitboards excel in pawnstuff. Unfortunately it completely doesn't matter
>because you hash the pawnstuff anyway.
Some of the pawn stuff is hashed. Some is not. But the issue was not
really efficiency, but "can it be done?" I don't see anything at all in
0x88 that can't be done in bitboards, and vice-versa. They are just
different approaches with different advantages. Move generation is a
different subject, based on generating captures-only, but that's yet another
topic..
>
>>
>>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.