Author: Robert Hyatt
Date: 19:22:37 02/02/02
Go up one level in this thread
On February 02, 2002 at 16:29:14, Vincent Diepeveen 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? >> >>Ed > >june 2001 article clearly says they did 4 ply in hardware and >first ply singular extension was possible in hardware. when search >took too long the hardware search was aborted and the position was >extended in software. > >This is how they got their long mainlines. > First, I have _never_ seen anything that said "they only did 4 plies in hardware". The article you are referencing was just a test they did to produce some data. I have also _never_ seen them claim to do SE in hardware. Belle didn't, and the DB "search" was a direct clone of Belle's search with similar extensions... which did _not_ include SE. SE would be a real pain in hardware. As far as "this is how they got their long mainlines" that is absurd just on the base analysis. >> >>>-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.