Author: Robert Hyatt
Date: 12:08:16 01/21/00
Go up one level in this thread
On January 21, 2000 at 13:56:40, Tom Kerrigan wrote: >On January 21, 2000 at 11:44:22, Robert Hyatt wrote: > >>It would run so much slower it would get killed tactically. Remember that their >>king safety included not just pawns around the king, but which pieces are >>attacking what squares, from long range as well as close range. Which pieces >>are attacking squares close to the king, etc. That takes a good bit of >>computing to discover. > >I realize that it takes a good bit of computing to discover. But I doubt it >takes so much that it's prohibitive. There are very successful micro programs >with extremely expensive evaluation functions, e.g., MChess and the King, and to >a lesser extent, HIARCS and Zarkov. These programs all reportedly have terms >similar to the ones you describe. I seriously doubt that the DB evaluation >function is an order of magnitude more complex than, say, MChess's... > >-Tom But they don't take the time to find out which pieces are attacking squares around the king "through" another piece. IE a bishop at b2 attacking g7, but only if the Nc3 moves. Or only if the pawn on d4 or e5 moves. That gets very expensive computationally. DB gets it for nothing. I think it would slow me down by a factor of 100 or more, depending on how far I wanted to take it... That might make me more aware of king attacks, but it would hide many plies worth of tactics since a factor of 100 is over 4 plies. Only a wild guess of course on the factor of 100, but since the eval is done at every node in the q-search, this is probably within an order of magnitude or two of the real answer. I can guarantee you it is more complex than the above evaluations. And I don't even know all the things they evaluate. One new idea mentioned in Hsu's book was the concept of "a file that can potentially become open" so that you put rooks on that file, even though you can't see exactly how you are going to open it within the 15 plies + extensions they were searching. "Potentially open" takes a lot of analysis on the static pawn structure. I do some of this pawn structure analysis myself, and even with pawn hashing it slowed me down significantly when I added it a year+ ago to better handle/detect blocked positions. Remember that they claimed about 8,000 static evaluation weights in their code, this reported by someone that went to a DB talk by Murray Campbell. 8000 sounds like a big number...
This page took 0.05 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.