Author: David Rasmussen
Date: 00:24:53 01/09/01
Go up one level in this thread
On January 08, 2001 at 20:31:02, Dann Corbit wrote: >On January 08, 2001 at 20:05:50, Landon Rabern wrote: > >>On January 08, 2001 at 14:23:48, Uri Blass wrote: >> >>>On January 08, 2001 at 13:41:43, Severi Salminen wrote: >>> >>>>>> >>>>>>Well, generating moves is slow >>>>> >>>>>I guess that it is your mistake. >>>>> >>>>>I do not think that generating moves is slow. >>>>> >>>>>I think that generating moves if you are interested in pseudo legal moves and >>>>>not in legal moves is very fast relative to other things that you want to do in >>>>>your chess program. >>>> >>>>I must disagree on this one. Yes, I am interested in pseudolegal moves and my >>>>engine also generates only them. But it is not _that_ fast. >>> >>>The question is what is your definition of being fast. >>> >>>I think that the right comparison is with the top programs. >>> >>>I know that top programs usually generate between 50 knodes per second and 500 >>>knodes per second on pIII450. >>> >>>If generating all the pseudo legal moves takes less than 1/500,000 second then I >>>think that you have no big problem. >>> >>>I also think that counting the moves is faster than generating them that means >>>that you save the information about the moves to use it later. >>> >>>If you have bishop at c4 you need to check if the first piece in the direction >>>d5,e6,f7,g8 and the first piece with it's colour determine the number of moves. >>> >>>You can continue for all the bishop's direction. >>>It seems only few clock cycles for every move. >>> >>> I have reprogrammed >>>>many move generation routines in assembler and they still take their time. I'm >>>>using bitboards not rotated, though. But using pipelining facilities of modern >>>>processors one can generate file moves very fast with only a couple of assembly >>>>instructions or clock cycles. >>> >>>How many clock cycles do you need to generate a move? >>> >>>Uri >> >>Yah, you can just get all the bitboards like normal, but then dont loop though >>and save the moves, just popcount the bitboards. Or if you only care about how >>many squares you can move to, not how many different pieces can move to those >>squares, you can or all the bitboards together and do 1 popcount. >> >>I have not tried adding mobility to my program yet, maybe I will. > >I'm not sure that counting moves will help a lot, or even if knowing you can >punch a hole will help. > >[D]2k2q2/8/3p4/2pPp3/1pP1Pp1p/pP3PpP/P5P1/2Q1K3 w - - > >This is a bad bishop sort of idea, but with only one piece that can punch a >hole, and (upon breakthrough) the piece dies. Still lots of places the queen >can move. But just no really useful ones. > >Not that I have a better idea. The position you gave is very extreme. No program will every reach such a position. And besides, that kind of mobility is meant as a general guide, not as the all important feature of an evaluation function. A carefully weighted mobility factor of the kind that is discussed here, will make the program play more active, all else being equal.
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.