Author: Dann Corbit
Date: 11:20:25 11/27/02
Go up one level in this thread
On November 27, 2002 at 13:02:19, Bob Durrett wrote: [snip] >To me, the gyrations a chess engine has to go through [alpha/beta and such], >other than execution of the evaluation "function," seem more like overhead. Of >course, this is merely my perception. Hard-core alpha/beta devotees would >probably take exception to this characterization. : ) The search also contains or uncovers knowledge. If you have the world's most brilliant evaluation and search 4 plies less deep than your very simple opponent, you are going to lose from that sometimes. It is an often debated idea (slow, smart nodes verses fast simple ones seems to be somewhat of a tradeoff). The exact balance between speed and knowledge is more art than science right now, I think. >>I have a hard time calling 50% of the total >>time "simple" myself, > >Well, there are two things being discussed here: (a) percentage of total >processor time used to perform position evaluation, and (b) complexity of the >evaluation versus the number of positions evaluated per unit of time. I don't think it can be made that simple. There are some things that are clearly essential in an evaluation function. In order of descending importance: 1. Wood count --> If you don't have a clear count of who's ahead in material, you are in deep doo-doo. 2. Pawn structures --> If you double and triple your pawns, shred your king's box and leave loads of backwards pawns and pawn islands, you will die a slow and painful death. Also includes passed pawns, doubled passed pawns, pawn trousers, etc. 3. King safety --> Checkmate is the object of the game. If you forget to protect the king, bad things will happen. More esoteric things but still needed in good engines: 4. Pins and forks --> good for the pinner/forker, bad for the pinnee/forkee. 5. Development --> Develop your army before you start the war. Don't castle too early or too late. Don't develop your queen too early. Knights before bishops. 6. Force --> Stack a bazillion pieces all aimed at a weak spot. Good for the stacker, bad for the stackee. 7. Bad bishops --> If the center is closed, then bishops drop in value. If a bishop gets closed off by a pawn wall, it becomes worthless. 8. Knight outposts --> If a knight has a protected post forward on the board, it is good. In closed positions, knights become stronger than bishops. 9. Space --> The number of squares behind your most forward pawns. You want to pinch the enemy's area and leave him cramped to move. 10. Board control --> The number of squares in the opponent's half of the board that are attacked by your pieces and pawns. 11. Pawn storms --> Especially in opposite castled situations, does your program understand pawn storms? 12. Massing your army near the opponent's king --> If you can move a lot of attackers in the king's quarter of the board, you build an advantage. 13. Rook(s) on the 7th rank --> The pigs are on the loose! Open files for your rooks. 14. Pawn races --> If you lose, then you LOSE. Probably, there are a lot more things of great importance. I would like to see the list expanded and also the order that both programmers and chess players assign to these elements. The biggest question is: "How fast can you accomplish these things?" >>since this is about 4,000 lines of code, roughly... > >Are all 4000 lines of this code within a single compact "function"? [Or is the >code somehow spread out here and there, willy nilly, throughout the Crafty >code?] Look at "evaluate.c" >It would be easy to feel that a 4000 line evaluation "function" might not be >"simple," but when taken in the context that you have 51,000 lines of code in >Crafty, 4000 doesn't sound like much at all!!!!!!!! The standard for programming is that a good programmer creates 10 lines of debugged code per hour. That means 400 hours. A "cheap" consulting rate for someone of Bob's ability is $100/hour. That means the evaluation function was a $40,000 development. >Anyway, my questions are driven by my perception that the evaluation function >size/complexity would be a critical parameter in chess engine design, at least >for the types of chess engines that do a lot of searching. Nobody can say if it is true, one way or the other. There is a program called Thinker. The whole program is: 10/02/2002 11:57a 81,920 Thinker.exe 82,000 bytes long. It's on a par for strength with Crafty and Phalanx. I'd like to know how in the heck he did that. >I really would like to know about the tradeoffs that determine: >(a) the number of lines of position evaluation code as a percentage of the total >number of lines of code of the chess engine, and >(b) the percentage of total processor time to devote to position evaluation. This is a forest and trees thing. Counting lines of code will definitely be a useless exercise to determine the strength of a chess engine. >How does the chess engine programmer decide which percentages to use? What are >the optimal percentages? [Please assume a mature chess engine (like Crafty), >and not one just started] The decisions have nothing to do with line counts and everything to do with forming an objective and achieving that objective efficiently.
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.