Author: Amir Ban
Date: 14:22:08 01/21/00
Go up one level in this thread
On January 21, 2000 at 15:08:16, Robert Hyatt wrote: >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 > Add Junior to the above list. > >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... It's big, but what does it really mean ? Some of it must have been piece-square tables for some features that were downloaded from the hosts, and that's hundreds of entries per feature. Besides, where is all this sophistication showing up in the DB & DBjr games ? Forget the numbers, whatever they mean. Show us the positions & moves. Amir
This page took 0.07 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.