Author: Steffan Westcott
Date: 15:15:49 11/20/02
Go up one level in this thread
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. >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). >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? >Btw. is your from/to-hashkey function fast enough to outperform two 64bit scans? Yes, thanks :-b 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.