Author: Gerd Isenberg
Date: 12:17:57 11/20/02
Go up one level in this thread
On November 20, 2002 at 09:37:11, Steffan Westcott wrote: >On November 20, 2002 at 07:35:46, Sune Fischer wrote: > >>You are right that would save time, but I wonder if not the book keeping becomes >>very complex. There seem to be two conflicting issues at work here, doing the >>least amount of effort and get a good move ordering. >> >>What I don't understand is how you do your move ordering (SEE or MVV/LVA) for >>captures, how do you access the history table without "to" and "from" squares, >>that kind of thing. >> >>I guess if you do something really simple like: Attack(Whitepawns)&BlackQueens, >>then you can generate that move(s) only and try that, no move ordering needed. >>But there are 5 pieces and each can attack eachother, so that must be 25 >>different checks. >> >>What am I missing here? > > >Sune, > >I perhaps spend a bit more effort than most on immediate move ordering when the >other heurisitics (transposition table, history, killers etc) are exhausted. I >have a high degree of overlap between (fundamental) position evaluation and SME >(Static Move Evaluation, a generalisation of SEE where the initial move is not >necessarily a capture). > >Your example, of testing for instances of the pattern P x Q, is not far off the >mark. The patterns I use for SME are *ahem* somewhat more complex, and mostly >resemble those of interest for standard SEE. The patterns are ordered (from best >to worst) and tested for matches on the board _when_needed_. It essentially >implements a static (predetermined) sequence of move types to try, ordered by >position features that can be discovered quickly without doing a search. >Optimisations are possible to skip patterns if they are known that they will not >currently match anything. For example, if no enemy queen is currently attacked, >all patterns ? x Q can be skipped. > >As for indexing the history table, I index it using a move hash value, not the >from/to square indices. It is merely a different hashing scheme than the >traditional [from][to] scheme. > >Cheers, >Steffan 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... 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. 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. Btw. is your from/to-hashkey function fast enough to outperform two 64bit scans? 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.