Author: Robert Hyatt
Date: 07:21:52 01/06/03
Go up one level in this thread
On January 06, 2003 at 09:38:58, Uri Blass wrote: >On January 06, 2003 at 09:28:53, Robert Hyatt wrote: > >>On January 06, 2003 at 02:19:13, Uri Blass wrote: >> >>>On January 06, 2003 at 02:02:34, Bruce Moreland wrote: >>> >>>>On January 05, 2003 at 23:21:40, Russell Reagan wrote: >>>> >>>>>It's probably best not to, since it is a linear improvement to an exponential >>>>>problem. Where the real improvements in playing strength will come from are >>>>>exponential improvements to the exponential problem (like null-move knocking >>>>>that branching factor down). Of course, I'm sure you already know this, and this >>>>>is your clever way of making others think about it for themselves and discover >>>>>the answer on their own, giving us all a greater sense of accomplishment and >>>>>self worth (not to mention saving us a great deal of time) ;-) >>>> >>>>Yes, I agree with this. The real improvement comes in doing new stuff, not in >>>>making the old stuff a few percent faster. >>>> >>>>Which is why I brought this up. If I could decrease bf by a few percent I'd get >>>>more speedup than I would by performance twiddling for years. >>>> >>>>bruce >>> >>>In my case I found that thinking about new stuff gave me idea to improve the >>>speed of Movei. >>> >>>I thought about implementing one of Ed's ideas and I found that changing my move >>>generator to find the biggest capture take too much time inspite of the fact >>>that movei generate the list of the legal moves >>>before making a move because I like to have the ability to use information about >>>that number for extension and pruning decisions. >>> >>>I decided to have special function of generating moves for non captures and >>>captures and it made my move generator faster. >>>I continued with adding special function for generating white pawn moves and >>>black pawn moves and even the function of white pawns I divided to generate pawn >>>move one square,generating pawn move two squares... >>> >>>I believe that it may be possible to improve the speed of all part of the >>>program by a factor that is bigger than 2 but new data structure is needed and >>>it is not simple to do it. >>> >>>I believe that all programs do too much the same thing again and again. >>>One example is that programs usually do not use the list of the moves 2 plies >>>earlier for generating moves and I believe that a big gain can be earned from >>>doing it but it is not simple to do it with no bugs so I even did not try to do >>>it. >>> >>>Uri >> >> >>Some do that. Including an early version of Crafty. However, generating >>all moves _can_ be faster than incrementally updating the move list from >>two plies earlier, which is why hardly anybody does this today. > >It is possible to remember for every piece a list of moves and in this case it >is possible to try to update the move list incrementally only for pieces that >did not move(because pieces that moved have usually different move list). > >Did you try to do it in that way in an early version of Crafty? > >Uri Yes. That is the way chess 4.x is described in the Slate/Atkin chapter of Chess Skill in man and machine. The work to update things was (for me) more than the work to just re- calculate the moves again. Remember that for me, I just look the moves for a piece up in a table with one memory access.
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.