Author: Robert Hyatt
Date: 09:01:53 02/02/02
Go up one level in this thread
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." IE I guess that if I had had that kind of design, I would probably shorten the reference to depth to just include the software depth since (at least for deep thought) it seemed that the hardware depth was generally statically fixed to 4 or 5 (I don't recall exactly which I saw). DB seemed to be a bit more dynamic in that they could do an 9(5) iteration and then either a 10(5) or 9(6) iteration next. That was why I specifically asked the question about the depth, because I had seem them use "depth" in what I considered to be an ambiguous way and after we all started examining their logs it seemed important to understand their stuff. There are other "hints" about this. Remember that the chess hardware has absolutely no way to return a PV move of any kind. So _every_ PV you see produced by their program was absolutely searched by the software part of the machine _only_. When you see 10(6) you can now _know_ that in addition to whatever PV you see (and it may well not be a full PV as they could only get the PV from the hash table which is not 100% reliable in producing moves particularly near the end of a PV) there _must_ be at _least_ 6 more PV moves (non-captures) plus the q-search moves. The Chess processors didn't do SE, but it did do classic extensions like in-check and recapture, because it was copied directly from Belle which did the same things. In short, _every_ PV you see has at least (N) more non-capture moves on the end of it, plus their q-search... If you look at their output carefully, you begin to get the idea of their search, because it is _definitely_ a fact that the hardware provides no PV information of any kind, period. Look at the PVs you see and when you realize that they can only come from the X(Y) (the X part only) part of the search, things begin to make sense. Vincent sees a 8(4) depth and 12 moves and says "aha, that is obviously a 12 ply search and PV" even though it should now be obvious that that 12 ply PV came from the 8 part of the software search, not from the 4 part of the hardware search. So far I have not seen anything that is inconsistent with anything they have said, _except_ that their branching factor seems lower than I would expect. This _could_ be caused by using alpha/beta triggered extensions that get hit more on PV searches and less on other searches. Or due to the not-very-well understood "hardware futility pruning" done in the chess processors. Clearly something is going on in their search that is "interesting"...
This page took 0.01 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.