Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Addressing frequently-discussed Deep Blue issues (from a FHH talk)

Author: Dann Corbit

Date: 18:39:28 10/07/02

Go up one level in this thread


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.



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.