Author: Robert Hyatt
Date: 19:25:10 02/02/02
Go up one level in this thread
On February 01, 2002 at 18:34:52, Andrew Dados wrote: >On February 01, 2002 at 18:08:39, Ed Schröder wrote: > >>On February 01, 2002 at 15:10:14, Andrew Dados wrote: >> >>>On February 01, 2002 at 00:28:08, Robert Hyatt wrote: >>> >>>>On January 31, 2002 at 14:04:13, Andrew Dados wrote: >>>> >>>>> >>>>> >>>>>From their own publication, 'Deep Blue', June 2001 >>>>>Example of search depths over one position >>>>>r1r1q1k1/6p1/3b1p1p/1p1PpP2/1Pp5/2P4P/R1B2QP1/R5K1 w >>>>>from DB-Kasparow game 2 from 1997, before move 37 >>>>> >>>>>When chips were set to minimum fullwith 4 plys: >>>>> >>>>>A.Iteration >>>>>B.Minimum software depth >>>>>C.Maximum software depth >>>>>D.Maximum Estimated combined depth >>>>> >>>>>A B C D >>>>>---------------- >>>>>6 2 5 11-21 >>>>>7 3 6 12-22 >>>>>8 4 11 17-27 >>>>>9 5 15 21-31 >>>>>10 6 17 23-33 >>>>>11 7 20 26-36 >>>>>12 8 23 29-39 >>>>> >>>>>So iteration is clearly the sum of minimum software depth (B) and hardware depth >>>>>(4 plys here). >>>>> >>>>>-Andrew- >>>> >>>> >>>> >>>>OK... but what does this have to do with the current discussion? DB doesn't >>>>report "an iteration number". It reports things like 10(6) and directly >>>>according to Hsu (from the email I posted) 10 is the software depth, and (6) >>>>is the hardware depth. They are _added_ to get the total depth... >>> >>>Why would they publish a table to depth 12 if they searched till d=18 in real >>>game? >>> >>>Recap: >>> >>>Arguments for depths of 17-18: >>> >>>1) Your email from Hsu >>>2) DB logs, which show something, like 8(4) line followed by 8(6) line. >>> >>>Arguments against reaching d=18: >>>1) Quotes by David Fotland from Dr Campbell on RGCC as I reposted here. >>> >>>2) According to their publication avg search speed over DB-Kasparov match was >>>126M nps. As you and Ed noted ebf of DB is 4. No matter how they prune, those 2 >>>numbers stand. >>> >>>Then time to finish depth 18 would be x*4^17/126Mnps, where x depends on search >>>model, qsearch, extensions, SE etc. That x can not be less then 30 (no qsearch), >>>more like 1000 for their search model. 4^17/126Mnps = 136 sec. >>>for x=30 we get 68 minutes to finish depth 18; for x=1000 we'll get 2266 >>>minutes. In the match DB searched for about 3 minutes/move. >>> >>>3) When DB sees some tactics in 10(6) line, is was noted that current PC >>>programs see that in depths 10-12 (current programs heavily prune and extend way >>>less comparing to DB). >> >> >>>No matter what is true, you have to agree some things are not consistent here. >> >>Right. >> >>Now let's have a look at things from Bob's point of view and assume the >>information is correct. Most of the time the logs shows 10(6) and 11(6). Can the >>host (the IBM RS/6000 SP from 1997) do a 10-11 ply brute force search with all >>those heavy extensions? If so, it then will all depend how fast the chess chips >>are doing their 6 ply searches. Each chip is claimed to do 2-2½M NPS. I can not >>find an average time for doing a typical 6 ply search in the hardware but if is >>an accepatable time it is maybe doable? > >As I recall chips were set to abort the search after 8000 nodes and report back >to host for possible split. So timeout would occur in 1/250 sec. I have no info >on average chip nodecounts, though. I thought the "8000" number was just one of hundreds of different values they tried? And that was an "endgame" number? This is hard to quantify as what was in Hsu's thesis was not what was done in deep blue and deep blue 2. Hsu's thesis was based on deep thought... he had long since finished his degree by the time the first DB processor was fabbed... > >> >>Ed >> >> >>>-Andrew-
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.