Author: Uri Blass
Date: 14:45:55 10/14/02
Go up one level in this thread
On October 14, 2002 at 17:36:11, Robert Hyatt wrote: >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... The problem is that Hsu did not mention the hardware search in his reply when the question was how is it possible that deeper blue did not search deeper than 12 plies. He could say that they also searched in the hardware so their 12 plies were more than 12 plies of deep fritz not only because of their singular and 2 logical move extensions. The fact that he did not say it suggest that the depth in the hardware was not additional depth(He also did not say it in his previous reply). 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.