Author: Dann Corbit
Date: 00:42:09 01/09/01
Go up one level in this thread
On January 09, 2001 at 03:24:53, David Rasmussen wrote: >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. It's a silly position all-right. But I remember watching a game where a computer put one of it's men in a box (against Steve Ham). The piece could still move, but it was useless for a long time.
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.