Author: Robert Hyatt
Date: 13:24:58 07/09/02
Go up one level in this thread
On July 09, 2002 at 15:22:45, Andreas Guettinger wrote: >On July 09, 2002 at 13:30:32, Robert Hyatt wrote: > >>On July 09, 2002 at 12:39:04, Martin Bauer wrote: >> >>>On July 09, 2002 at 11:54:17, Robert Hyatt wrote: >>> >>>>We did this in Cray Blitz. We had an additional 64 square "chess board" but >>>>rather than the piece id for a square, it was a pointer into the piece list >>>>so that we could remove (we just zeroed it actually) the entry. >>> >>>Sounds good, thanks >>> >>>>We then >>>>iterated over this list generating moves, which worked great on a vector >>>>machine. >>> >>>If you just zeroed the entry of an removed piece, you must always loop over the >>>complete List with 32 entries? >>> >>>Like: >>> >>>for i := 1 to 32 do >> >> >>No. You only do the first half or the last half depending on which side >>is on move. >> >>We further had a first and last pointer for both white and black. So that >>as a piece is actually removed from the board at the root, the lists get >>smaller. Within the search, we looped over the entire original half of the >>list, but with vectors that was free. > >This is exatly what I do in my engine right now. The pieces list is at maximum >as big as the number of pieces when starting the search. At start of the search >process I scan the board and generate the pieces list. After that I update it in >doMove() undoMove(), and I also update the 64 square array which holds the >pointers to the pice list. > >Once a capture is made I zero the place in the list but i store the list >position so undoMove() puts the figure back at the same list position. This >speeded my 0x88 search up 20% compared to scanning the board every time before >generating moves. The piece list is also usefull in eval(). > >I once tried to update the size of the pieces list dynamically, so that it >shortens after a capture in the search. I had the idea to change the current >list position of the deleted figure with the last one and zero it. undoMove() >should then ad the figure back at the end of the list and change it back with >the original place. But somehow I never got it to work, and it was not worth >becuse the additional code would slow down doMove() and undoMove(). So zeroing >is ok, I think. > >Andreas The obvious answer is a linked list rather than a simple vector of piece indices. However, whether it will be worth the trouble or not is debatable.
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.