Author: Volker Böhm
Date: 23:02:26 03/05/04
Go up one level in this thread
On March 05, 2004 at 17:52:07, Russell Reagan wrote:
>On March 05, 2004 at 16:33:36, Volker Böhm wrote:
>
>>to get every pawn I don´t whant to walk through the board. Currently I am
>>storing piece lists for every kind of piece. But this makes the do und undo move
>>a little too costy as I have to search through the piece list to find the right
>>one.
>
>I would recommend having seperate piece lists for each kind of piece, and then
>have your board be an array of pointers that point to the piece on each square.
>If a square is empty, you can make it a null pointer, or have it point to some
>invalid piece that you never use for anything else.
>
>>If for example I hit a piece I have to scan through the piece list, remove
>>the piece and fill the hole from the end.
>
>There are two ways of doing this I think. One is to shorten the piece list when
>a piece is captured, so that all pieces in the list are always valid pieces on
>the board. The other way is to add a 'status' flag to the piece indicating
>whether it has been captured or not. So when you generate moves, you would do
>something like this:
>
>for (i = 0; i < number_of_pawns; i++) {
> if (pawns[i].status == captured)
> continue;
> // generate move for the pawn
>}
>
>>I´am thinking about storing the piece-list-index in the board to find the right
>>position of the piece in the piece-list quickly. That could get a little
>>speed-up.
>
>Yes, that is essentially the same idea as what I described above, only I used
>pointers and you used indexes. Same concept though. I prefer the board of
>pointers to a list of pieces over a list of occupied squares, because I often
>find myself looping through the piece list and to loop through the piece list
>requires two array lookups if you just store occupied squares.
>
>>But I haven´t a good idea to keep the order of the piece list identical if I
>>do/undo a hit move.
>
>Why do you need to keep the order of the piece list the same always? When a
>piece gets captured, just decrement the piece count for that piece type, then
>move the last piece in the list to the element of the list where the captured
>piece used to be. When you undo that move, just add the piece to the end of the
>list and increment the piece count.
The order is not quite neccessary, but it would be nice to make debugging
easier.
I have a reference game where I search every move with depth 8 and count the
total nodes. If ever I change something that should´nt change the way my
programs search (for example speed-ups) I run the reference-game check to see if
I haven´t entered a bug (if I get the same node amount, no bug). If I change for
example the way check situations are detected (set move, check if in check, undo
move) then I change the order of pieces and the count of total nodes.
Other Point: if I, while debugging without hash, killers and history call a
buggy subtree then call it again because I know now that this is the subtree
with the bug, then perhaps the bug is not longer shown as the piece order has
changed.
>
>Let me know if anything I said was confusing and I'll try to explain it better,
>and provide examples if you would like them.
All quite clear. Thanks!
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.