Author: Vincent Diepeveen
Date: 15:00:25 05/27/02
Go up one level in this thread
On May 26, 2002 at 18:14:00, Robert Hyatt wrote:
>On May 26, 2002 at 16:29:31, Vincent Diepeveen wrote:
>
>>On May 26, 2002 at 11:33:26, Robert Hyatt wrote:
>>
>>>On May 25, 2002 at 09:50:27, Vincent Diepeveen wrote:
>>>
>>>>On May 25, 2002 at 09:32:58, Russell Reagan wrote:
>>>>
>>>>A few rude things can be done pretty quick with bitboards
>>>>at 64 bits processors, which is what Bob aimed at a year
>>>>or 10 ago,
>>>>but as soon as you want to evaluate things in detail, then
>>>>please remember what bitboards are: they provide 1 bit of
>>>>info a bitboard about a square. That's very little info.
>>>
>>
>>May i refer to our discussion a year ago where i took
>>attacktables and keeping them incremental updated as
>>example.
>
>
>May I refer to my response? If I want attack tables, I can create and keep
>attack tables. The basic "bitboard" being discussed is a chess board
>representation only. I used to keep different sorts of attack tables but
>got rid of them because I found other ways to do whatever was needed, at a
>cheaper cost.
May i refer to the proof then why it is so much slower for DIEP,
because i need that information into my evaluation everywhere and
in crafty you need to combine all the bitboards in order to get
the info out. For example to get the number of attackers which i
use a lot, you need to perform all kind of slow adds, which i have
already incremental available with a single AND to the array.
The reason for this is that you have only 1 bit of information i
can use in each bitboard. Whereas i have the info already combined into
an array which gets incremental updated for each square!
So i am NOT off the mark. It is the 'little information a square'
versus 'all information a square' lemma. A classical difference
between bitboards and 'gnuchess 4.0' representation, whatever name
you want to give it. Mailbox or 0x88 or whatever.
Using incremental datastructure i do:
attackers = (a1&15);
Bitboard equivalent is something primitive such as:
attackers = 0;
for pieces = 0 to 16 // all pieces
if( !thispiece && bitboard[piece]&squaremask )
attackers++;
Of course i realize you can do it without branches by adding
some more instructions. But we talk about 15 bitboards you need
to combine or so. Not very nice thing to do!
Your response was: "i don't need the number of attackers".
I give this example, but there are many other things with regards
to evaluation i would love to show, but i dare not show out of paranoia
that others might consider using it in their evaluation, where i
didn't found an easy solution for with bitboards.
I just show one example here. If you say: "i don't need the number of
attackers, my program is doing without that information fine"
Then i accept that statement of course, like i did a year ago.
It just means that bitboards are unusable if one desires to use more
information for a chess engine.
>But as far as the "not much information in a bit" that is well off the mark.
>IE one bitmap to list all squares attacking a specific square. All squares
>attacked by the piece on a specific square. All the pieces of a particular
>type anywhere on the board. Etc. Fairly dense...
>
>
>>
>>Best regards,
>>Vincent
>>
>>>OK.. you have an array board[64] (or whatever). Exactly how much
>>>info does board[i] provide? ie assume a white knight is on square
>>>i. Exactly how much information do you get from board[i]? From
>>>my "white_knights" bitboard I find the location of _all_ white
>>>knights. Not just one...
>>>
>>>Your example is not so good...
>>>
>>>
>>>>
>>>>So obviously when you require many details about a certain
>>>>square, which makes other methods galaxies faster
>>>>than bitboards.
>>>>
>>>>There are even several ways to do it faster.
>>>
>>>
>>>Including faster than the way you are doing things. Bitboards have some
>>>serious advantages on 64 bit machines, and they make evaluation very nice
>>>in many cases... Particularly when looking for "patterns"...
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>>I hear about how great bitboards are because they [insert one of the many
>>>>>reasons here]. I'm interested in two reasons in particular, because I do not see
>>>>>how these reasons work.
>>>>>
>>>>>The first thing I'm curious about is computing whether or not a square is
>>>>>attacked by a certain side. This is supposed to cost about a couple of array
>>>>>lookups and an AND operation, right? Look up the white king bitboard, look up
>>>>>the black pieces attack bitboards, AND them together, and you can tell if the
>>>>>king is in check. That's what I've always heard anyway. Clearly this is much
>>>>>faster than ray tracing the board looking for opposing pieces, but I don't see
>>>>>how this bitboard method would even work. For example, for this to work, you
>>>>>have to have a valid "black pieces attack" bitboard. To compute this you could
>>>>>OR together all of the attack bitboards for each piece. The problem is that you
>>>>>have pseudo-attacks. So this computation above where bitboards calculate whether
>>>>>or not a square was attacked really only says "this square MIGHT be attacked",
>>>>>right? At which point, you would have to do the ray tracing anyway, and it's not
>>>>>really any faster, right? I'd like some clarification on this.
>>>>>
>>>>>The other thing I recall Bob saying was that using bitboards you can calculate
>>>>>mobility for "free". Again, this seems like you could calculate pseudo-mobility,
>>>>>but to calculate actual mobility, you'd have to do ray tracing just like you
>>>>>would with another board representation scheme. I'd appreciate some explaination
>>>>>of this also.
>>>>>
>>>>>Thanks,
>>>>>Russell
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.