Author: Brian Richardson
Date: 13:09:07 06/13/02
Go up one level in this thread
On June 13, 2002 at 15:07:25, Dann Corbit wrote: >On June 13, 2002 at 14:45:06, stuart taylor wrote: >[snip] >>That's great! I didn't realize it was you. >>I wish you great success, and I'm sure you might eventually become no.1 on >>ssdf! (but don't waste too much time over it).] > >I think Uri has taken a very wise approach. He spent a great deal of time >optimizing a move generator. This is the heart of a chess program. A program >that has everything else excellent, but an average move generator can become >strong but not a superstar, because it will become a bottleneck at some point. At some point yes, but long after the eval and search bottlenecks are reached. I suspect most programs spend about 5-10% time in generating moves, and 30+% time in eval. Also, where does the move generation strictly stop? There are also attacks, SEE, mobility, etc. All of these functions may or may not use move generation. When I doubled Tinker's make/unmake move time by adding hashing and several other incremental updates, the overall speed impact was only about 2%. > >Once you have a vast framework in place, it becomes more difficult to change the >powerplant that sits underneath. If you have chosen objects and encapsulate >everything well, it becomes less difficult, but you would have to be very clever >to have no rippling effects to doing major surgery on your move generator. It >is pretty hard to write a capture function (for instance) that does not have >intimate knowledge of the move generator. As an interesting exercise, try to >imagine a capture function that can operate identically without knowing whether >the board is in 0x88 or in bitboard format. > >But a move generator is one of the necessary (but not sufficient) techniques on >the way to a great chess program. It must also be tactically excellent. It >must be relatively bug free (probably one of the hardest to achieve). It will >have to have an excellent search method (either pvs, mtd(f), or something equal >to it undiscovered). It will need some innovations and some positional >understanding. > >However, I think Uri's approach is a very sound one. Start with a solid >foundation and build upon that. Take incremental steps towards a goal. Since >he is also an excellent chess player, I expect that he can insert special >knowledge into his program and know when it is doing something awful (not always >as easy as it sounds for us patzers).
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.