Author: Robert Hyatt
Date: 20:08:03 10/07/02
Go up one level in this thread
On October 07, 2002 at 21:39:28, Dann Corbit wrote: >On October 07, 2002 at 21:35:23, Robert Hyatt wrote: > >>On October 07, 2002 at 19:40:16, Tom Kerrigan wrote: >> >>>1. Deep Blue _did_ do forward pruning. They used null move for threat detection, >>>not forward pruning, but they did have "domain specific" forward pruning. Hsu >>>emphasized this quite a bit. He said specifically that it was responsible for >>>allowing them to search critical variations very deeply. >>> >>>2. Deep Blue did _not_ have impossibly sophisticated eval terms. Hsu gave two >>>examples of DB's "extremely costly" eval terms: >>> >>> i. Seeing if an open file is valuable by calculating the square control of >>>the 7th and 8th ranks of the file (including rays) >>> ii. Doing king safety calculations for both sides of the board while the >>>king is uncastled. >>> >>>Many PC programs calculate square control and could easily/cheaply implement >>>(i), and (ii) is not THAT expensive. If king safety takes 10% of a PC program's >>>time, doing it twice would only make it 10% slower (and only in positions where >>>kings aren't castled). >>> >>>Moreover, Hsu said that a major limitation of DB1 (that was fixed in DB2) was >>>that square control information could only be used for a limited number of eval >>>terms, apparently because it was available late in the eval pipeline. So there >>>were limitations to the eval terms that could be computed by DB. >> >> >> >>A couple of points. (1) nobody said they had "impossibly complex eval terms". >>I (and the DB team) _did_ say that they could do whatever they wanted. If >>something is ready "too late" all you need to do is extend the pipeline a cycle, >>and let -er rip.... _if_ you really want that eval term and it is serially >>based on >>something that has to be computed first... Compare that to what _we_ have to >>do which is to serially compute _everything_. (2) what is so important about >>DB1? DB2 was _the_ machine... and he fixed a _lot_ of problems from DB1 >>in the re-design... >> >> >> >> >>> >>>3. There _was_ an implementation of DB's algorithms in software. I asked how the >>>new eval terms in the DB2 chips were tested & tuned without actually having the >>>chips, and Hsu said that Joel Benjamin played a "software simulation" to test >>>them. He made it sound like that should have been obvious. (Are you listening, >>>Bob?) >> >> >>Never said there was _not_ one. I said "there was no reasonably efficient >>software implementation" that could be used in an engine." Big difference. >>You _can_ emulate _anything_ in software, by definition. But that doesn't >>mean you can use it to play games... >> >>They discussed their "software tuning" more than once, and apparently had some >>sort of GUI interface to the process... >> >> >>> >>>4. While he does have the rights to the DB chip design, Hsu is still bound by >>>IBM NDA for the eval terms and is not legally allowed to disclose them. >>> >> >>Nothing surprising there. > >The software tuning algorithm is found at Tim Mann's site. Also included is the >data that was used to drive it. >If you have a POSIX workstation, you will even get the icky curses interface >along with it. Actually that is the _deep thought_ tuning program. A long way from the GUI-based stuff they did for DB1/DB2.. I have had a copy of the deep thought stuff forever, sent to me by Andrew N. But it was _really_ old stuff based on deep thought...
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.