Author: Gerd Isenberg
Date: 23:32:50 11/20/02
Go up one level in this thread
On November 20, 2002 at 18:15:49, Steffan Westcott wrote: >On November 20, 2002 at 15:17:57, Gerd Isenberg wrote: > >>Hi Steffan, >> >>I guess your serialized move structure containes at least one bitboard, with >>"ored" singular source and destination boards, easy to separate (source = bb & >>ownpieces), nice for immediate updating the complete board representation, but >>some more memory traffic for the move list. >> >>I'm also thinking about this issue, inspirated by your recent posts. >>Doing bit scans and rebuilding a singular bitboard later by 1<<sq all the >>time... > >Avoid anything to do with bit indexing as much as possible! See my reply to >Alessandro for some detail on my 'movelist' representation. > Yes, but my current program does. >>With a smart finite state move generator, i think it is best looking for >>validity of killers and may be capture last moved or enprised pieces without >>further generating and the need of complex bookholding. > >I generate all pseudo legal moves in one go (even before looking in the >transposition table) and initialise my movelist. This avoids repeated work when >validating moves suggested by the various standard heuristics (history, killer, >etc). Aha, i see. > >>Don't like the idea of too many recursive bitboards in my node class, happy >>about throwing some rotated bitboards out. I like your mentioned unique >>direction target moveboards on the stack. > >I don't understand what you mean by 'recursive bitboards'. Could you expand on >this? Recursive variables, local variables in recursive functions. I ment statefull (bookholding) bitboards, which are used during finite state machine move generation, and therefore needed in every node of a path from root to leaf. If i understand it right, that is exactly what you do, as a form of this fixed unsorted pseudo movelists. I guess eight bitboards for queens and knights each, four for bishop, rooks and three for pawns and for the king one is enough. > >>Btw. is your from/to-hashkey function fast enough to outperform two 64bit scans? > >Yes, thanks :-b Aha, what magic function could that be? Mod sucks... But you don't need to tell too many implementation details of course :-) Cheers, Gerd > >Cheers, >Steffan
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.