Author: Alessandro Damiani
Date: 04:24:59 10/25/02
Go up one level in this thread
>>>The implementation of generating moves in chunks is easily done by encapsulating >>>all work in a method that returns the next move: >>> >>> Move nextMove(int ply, ...) >>> >>>The value 0 is returned, if there is no move anymore. >>> >>>The method nextMove() has a state for each ply: in which generation phase it >>>currently is. For instance, our move ordering is >>> >>> 1. hashmove >>> 2. winning captures >>> 3. killer 1 >>> 4. killer 2 >>> 5. equal captures >>> 6. non captures >>> 7. losing captures >>> >>>We define the following phases: >>> >>> PHASE_HASHMOVE 0 >>> PHASE_GENCAPTURES 1 >>> PHASE_POSCAPTURES 2 >>> PHASE_KILLER_1 3 >>> PHASE_KILLER_2 4 >>> PHASE_EQUALCAPTURES 5 >>> PHASE_GENNONCAPTURES 6 >>> PHASE_NONCAPTURES 7 >>> PHASE_NEGCAPTURES 8 >> >>Today I also have phases nit clearly less phases than you. > >1)It should be but and not nit(*ni* are close to *bu* in my keyboard and this is >my excuse for this mistake) > >2)The question that I ask myself is how to do the change to do movei faster. > >The point is that I want to do one change and test and not to divide the move >generator to a lot of functions. > >I do not like the idea of a function that is only for generating next move. > The function nextMove() does not generate moves at all! It uses the move generator(s) when needed. >The problem is that in case that I generate few moves and they do not help then >I may need probably to generate all of them so >I do not save a lot of time by this and I suspect that I use more time in that >case because I need to check that the next move that I generate is not in the >list that I already generated. > With bitboards separating generation of captures from the one of non captures pays off. >Generating the last move is espacailly slow and can take o(n^2) >because after doing the steps to generate a move I need to compare it with >average number of about n/2 moves only to find that the move alreasy appeared in >the list. > >It may be possible to do it faster by having a big array for the moves that >appeared but I do not like having some big array and it seems more complicated. > >I wonder how people who use incremenatal move generator(one after one) can make >it fast when there is no rules for the previous moves(hash, killers,captures). > >The only case when I understand how it can work fast is if you simply generate >pawns moves and later knight moves,..bishops move,rook moves,Queen moves,King >moves when you have only few moves that you remember but with all the phases >that are defined in this post it does not seem to be the case. > Keep in mind how your moves should be ordered. It does not make sense to develop the fastest move generator that generates one move each time, and then realize that one needs to order moves. If you use the history heuristic then you have to find the move with the highest history value. This works against your one-by-one move generator. Another thing: the method nextMove() produces one move each time, but move generation and ordering is hidden inside. Alessandro
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.