Author: Robert Hyatt
Date: 19:54:36 01/21/00
Go up one level in this thread
On January 21, 2000 at 17:22:08, Amir Ban wrote: >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 It would seem that the _results_ would speak for themselves. Who else has produced results like theirs?
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.