Author: Robert Hyatt
Date: 14:36:11 10/14/02
Go up one level in this thread
On October 14, 2002 at 15:54:10, Bas Hamstra wrote: >On October 14, 2002 at 15:24:57, Robert Hyatt wrote: > >>On October 14, 2002 at 15:17:20, Uri Blass wrote: >> >>>On October 14, 2002 at 13:48:26, Robert Hyatt wrote: >>> >>>>On October 14, 2002 at 07:34:16, Bas Hamstra wrote: >>>> >>>>>Bob, did you read the Hsu transcript posted here? It is pretty clear to me that >>>>>Hsu himself says 12 ply fullwidth *total*. Case closed. Please read the complete >>>>>transcript. >>>>> >>>>>Best regards, >>>>>Bas. >>>>> >>>> >>>>I read it, and I posted the relevant part. He said "12 plies is brute-force >>>>part >>>>of search". 6 plies is hardware partition. there could be up to 6 more plies >>>>beyond the 12 ply PV. >>> >>> >>>Here is part of the discussion that I copied >>>******************************************************************************* >>>EeEk(DM) kibitzes: kib question from ardee: Does "12(6)" mean 12 total ply or >>>12+6=18 total ply? This has the been source of huge arguments for years! >>>aics% >>>CrazyBird(DM) kibitzes: 12 total in terms of brute force. 6 is just the max >>>partition in hardware. >>>aics% >>>******************************************************************************* >>> >>>I understand from it that 6 is the maximal part in the hardware of the 12 plies. >>> >>>Max partition means max part. >>>The number 18 was not mentioned in Hsu's reply so it seems clear to me that he >>>meant part of 12. >> >>Then what did his very next sentence mean? "Up to 6 additional plies beyond the >>PV"??? >> >>Everyone is stopping _before_ Hsu did. that last sentence is important, IMHO. >>As it >>means the question is still not answered in a way that is precise enough to >>satisfy me >>completely. >> >>IE 12 plies in software + hardware? (doesn't match the statement) >> >>12 plies in software plus _up to_ 6 more, done by hardware (possible match with >>statement) >> >>12 plies in software plus 6 more in hardware (doesn't quite match statement, >>because it says >>"up to".) >> >>So it isn't clear. >> >> >> >>> >>>In case that it was 12-18 plies I expect Hsu a reply like the following: >>> >>>"12 total in the software(brute force),6 is the maximal additional plies (not >>>brute force) in the hardware". >>> >>>Uri >> >> >>That is the way I am interpreting his answer, in fact, since it correlates well >>with the >>emails I have from others on the team that also asked him this question for me. > >The question was asked twice. The second time was the most specific. When asked >why DB did NOT search deeper BF than nowadays nullmove programs, Hsu answers as >follows: > >CrazyBird(DM) kibitzes: 12 total in terms of brute force. 6 is just >the max partition in hardware. >EeEk(* DM) kibitzes: question from parabola444: You mentioned Deep >Blue searched about 12 plies brute force + extensions, which is >similar to what pc programs these days get on a fast pc - since Deep >Blue hardware was much faster, how come it didn't search significantly >deeper ? >CrazyBird(DM) kibitzes: we were using fairly extensive search >extensions, and the decision not to use null move pruning was an >deliberate one. >CrazyBird(DM) kibitzes: there were several reasons. >CrazyBird(DM) kibitzes: first, we were always at the top of the heap, >and the occasional error introduced by null move could cause us to >lose games to lesser programs. >CrazyBird(DM) kibitzes: second, we observed that we were zugzwanging >null move using opponents, which made us suspicious of it. >CrazyBird(DM) kibitzes: third, it is not clear how to incorporate with >singular extensions & null move pruning. they did not seem to be that >compatible. though Ferret seems to suggest that it is possible. >anyway, given that singular extensions are considered far more >important in creating deep lines, we keep what we know. >CrazyBird(DM) kibitzes: fourth, and not least, speed was more than >adequate, and we did not need to resort to null move. > >So? Note carefully that he does NOT deny that DB searches as deep as the average >nullmover (=12 ply) AT ALL. Isn't that a tad strange, when in reality it >searches more like 18 ply brute force? In stead he says "yes we are doing 12, >BUT we have clever extensions and no nullmove". So 12 ply. > >Best regards, >Bas. It isn't "strange" at all, because he has _specifically_ said "the hardware was not brute- force". I don't see the problem...
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.