Author: Gerd Isenberg
Date: 10:12:09 10/24/02
Go up one level in this thread
On October 24, 2002 at 07:09:17, Uri Blass wrote: >How many function do you have in an incremental move generator? > >If I understood correctly programs use > >1)Generatehash(generates nothing if the hash move is illegal or null) >2)Generategoodcaptures >3)Generate killer1(generates nothing if the first killer is illegal) >4)Generate killer2(generates nothing if the second killer is illegal) >5)Generating rest > >I think that 1,3,4 may be the same function because in all of them I need to >check if a move is legal when I have the move(includes the from square the to >square and more information in case of promotion). > > >I first think only to have generatehash and generaterest but generaterest >already means that I have to change my move generator. > >I doubt if generating rest is faster than generating all because I need to check >for every candidate move that it is not a previous move that I already >generated. > >Uri Hi Uri, My movegen states (i don't use SEE yet): 1. HashMove 2. Capture(s) last moved piece incuding ep 3. Captures of not defended pieces or more valuable pieces 4. (Covered) Check Captures 5. Captures of defended equal valued pieces, promotions 6. Remaining Captures of pieces, not defended by pawns 7. Killers (three additional) 8. (Covered)Check Moves 9. Pawn Moves and Moves to targets not attacked by opponent pawns 10. Remaining Captures of pawns/pieces defended by pawn 11. Remaining Moves to targets attacked by opponent pawns In my recursive node structure i have one "finite machine" state-integer, two movelist-indizies (one for the next getMove, one for the next pushMove) and three bitboards for bookholding (CapturesFrom, MovesFrom and Targtes). I use several routines to generate moves/captures _from_ a set of squares or _to_ a set of squares, which tag these bitboards for bookholding reasons. During generation the captures became an initial score based the material gain, the none capture moves a score based on history and countermove heuristics. If the movelist is currently empty, i do some move generations depending on the current state and switch to the next state. Even if the current move list is not empty, some states imply some more move/capture-generations, before they will pick the best so far out of the move list. In interiour nodes (depth > 2) i generate all and use more sophisticated sorting, which requires doing/undoing moves. May be you are right that this kind of incremential move generation requires too expensive bookholding overhead. Considering that 90-97% of the beta cuts are forced by the hash move... I'm currently thinking about a redesign of my move generator, also caused by Steffan Westcott's ideas of generating disjoint move target sets for each sliding direction. Regards, Gerd
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.