Author: Bob Durrett
Date: 14:00:33 11/27/02
Go up one level in this thread
On November 27, 2002 at 14:20:25, Dann Corbit wrote: >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. Someone needs to tell Bob Hyatt about this. He could be rich! 51,000 lines of code divided by ten and then multiplied by $100 would be, I think, a half a million dollars! Bob could purchase a really fancy multiprocessor computer for that! I'll bet he has never thought about it. : ) > >>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. Cough, cough, cough. : ) Bob D.
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.