Author: Uri Blass
Date: 09:34:06 02/02/02
Go up one level in this thread
On February 02, 2002 at 12:01:53, Robert Hyatt wrote: >On February 01, 2002 at 13:33:51, Ed Schröder wrote: > >>On February 01, 2002 at 09:05:35, Robert Hyatt wrote: >> >>>OK Here is the email again: >>> >>>My first question to them was "did the X(Y) depth notation in Deep Thought >>>mean X plies in software, Y additional plies in hardware as it did when I >>>watched your program?" Here is a reply from a member of the team: >>> >>>Quote On--------------------------------------------------------------------- >>> >>>In the DT logs, the number in () after the plies is indeed >>>the depth of the HW. It was changed dynamically, but only >>>within a narror range (3, 4, somethimes 5). I would not >>>be surprise if CB kept this notation, but I don't know for >>>sure. >>> >>>As you say, too >>>low, and the HW ends up idle because the host is too slow. >>>Too high, and the host is bored... >>>However the real reason for not letting the HW go too deep >>>is search efficiency: the HW does not use the transposition >>>table, hence it was best to balance the memory bandwidth >>>availabe on the host for hash table accesses. >>> >>>Quote Off-------------------------------------------------------------------- >>> >>>The second quote came as a response to my question "Does DB report the >>>depth using the same form of the X(Y) notation as was used in Deep Thought?" >>>Here is the answer, again: >>> >>> >>>Quote On--------------------------------------------------------------------- >>> >>>Hi, >>> >>>CB is in town this week and I had lunch with him, where we >>>chatted a bit about DB and the like. A while back, when you >>>looked over DB's logs (put up by Murray without IBM careing >>>much), you were impressed by their depth and branching factor. >>> >>>Well, the depth notation is as I told you and just like it was >>>in DT, so it really does go *that* deep... >>> >>>For example, in DT, 9(4) meant a 13 ply search. >>> >>>Quote Off-------------------------------------------------------------------- >> >> >>The last sentence is very convincing. >> >> >>>That is the best I can do. I asked about DT, which I saw _many_ times from >>>behind their monitor and they explained the X(Y) notation as I have reported, >>>several times. I then asked if DB kept the same notation and CB (nickname for >>>Hsu) said "yes it did." >>> >>>Can it be any more clear than that? >> >>No it can not, according DB team 12(6) = 18. >> >>However the statement conflicts with their own documentation, hence the >>confusion. >> >>So maybe I am wrong about the subject. >> >>Ed > > >As I mentioned in the past, on more than one occasion they had said "we did >an N ply search there" and when I saw their output it said N(X). I didn't give >it any thought until I finally asked "what is that X value?". And Murray or >Hsu explained it. I then asked "why did you say N ply?" and one of them >responded "the hardware search is much simpler than the real software search >and we tend to think of that as a unique form of a 'static evaluation' even >though it does include a search + capture search." I guess that the reason is simply that it was basically selective search that is clearly more selective than the search that other programs are doing when they search X plies. This search can include moves that are not captures but I guess that it includes only part of them and is more selective than normal null move pruning. I see no reason for them to say N(X) and not N+X(X) if it is not the case. 12 plies brute force+6 plies selective search in the way that Crafty or Rebel or another top program of today do seem to be impossible even when I know that 12(6) was only in part of the cases. Top programs often need about 100Knodes for searching 6 plies when it seems that the hardware of deeper blue needed only 8 Knodes when the hardware could not use hash tables if I understand correctly. Uri
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.