Author: Sune Fischer
Date: 03:20:33 07/10/02
Go up one level in this thread
On July 10, 2002 at 04:58:58, Andreas Guettinger wrote: >On July 09, 2002 at 23:41:39, Russell Reagan wrote: > >>On July 09, 2002 at 20:20:16, Benny Antonsson wrote: >> >>>Then there would be a "hole" at index 4 ? (no piece) >> >>No. Maybe I explained it wrong. If you have a piece list, and you want to get >>rid of the piece at index 4, then you swap what is in index 4 with what is in >>the last index. Then you decrement the size of the piece list. Maybe a simpler >>example would be more clear. >> >>Here is your piece list: KRBP >>The size of the list is 4 >> >>Now you want to remove the rook because it got captured (or whatever the >>reason). Now you switch the rook with the last piece, which is a pawn. The new >>piece list looks like this: KPBR. Now you decrement the size of the piece list, >>so the rook is still there on the end of the piece list, but when you iterate >>over the piece list, you will iterate over one less piece (since you decremented >>the size of the list). So your loop over the piece list would only produce KPB >>now, and you have removed the rook from the list (or so it appears). >> >>The piece list still contains the rook in the index 3, so if you want to add the >>rook back, you just increment the size of the list and now when you loop over >>the list you will "see" the rook again. >> >>A side effect of this is that the list will now look like KPBR instead of KRBP. >>So if the order of the pieces matters to you, this approach will not work. >> >>Another approach that might work is to have a 3D array of pieces as is done in >>EXChess. >> >>Russell > >I really like this linked list idea from Hyatt. I have to clean the dust from my >C book and look it up once. Has anybody a linked piece list in his engine? > >Andreas IMO, simpler is better. Unless you find this very simple then you shouldn't bother. If this is you first attempt to write an engine, then I suspect you don't really know what you'll be needing. A linked list may be short, and so "copying" (for undoing a move) will be faster in the endgame with few pieces. You don't have any holes in the list, so scanning the list should also be fast. But your method for deleting and setting pieces at a capture move will be slow, and there are _a lot_ of captures in a search (because they are tried first and done almost exclusively in the q-search). You also have a few extra pointers to carry around, and more data is slower in itself. What I like is the posibility to ask all kinds of different questions, like how many pawns do I have left, where are my rooks, are my bishops on opposite color, with minimal effort. I think these questions don't answer easily on a linked list, so as a first implementation you should opt for something easily implementable and debuggable, you will probably want to try different ways later anyway so don't waste a h*ll of a lot of time optimizing every line. Move generation is just a small part of the overall engine, and you need to think further ahead most of the time. I have have done this scheme on a regular array, it was really a mess and took me weeks to get working, so I wouldn't recommend it to my worst enemy:) I have now found something that is not only faster in nodes per second, but also generates more of the information I want, or at least the information can be generated with very few operations. Basicly it is a hybrid bitboard and mailbox, but the details are complicated. The best thing to do, if you absolutely must get it right on the first attempt, is to look through some of the strong opensource programs. In the strong progs there has been given a great deal of attention to all the details. Even if you find something to be illogical, it is probably not, and I'm sure most authors will be happy to answer any questions you might have :) -S.
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.