Author: Robert Hyatt
Date: 06:53:42 10/12/02
Go up one level in this thread
On October 12, 2002 at 08:29:24, Omid David wrote: >On October 11, 2002 at 21:57:34, Robert Hyatt wrote: > >>On October 11, 2002 at 17:51:27, Omid David wrote: >> >>>On October 11, 2002 at 11:51:13, Robert Hyatt wrote: >>> >>>>On October 11, 2002 at 07:43:40, Uri Blass wrote: >>>> >>>>>On October 11, 2002 at 07:12:34, Vincent Diepeveen wrote: >>>>> >>>>>>On October 11, 2002 at 04:08:49, Uri Blass wrote: >>>>>> >>>>>>Isn't his article clear enough yet? >>>>> >>>>>Bob Hyatt still claims that it was 12 plies software and 6 plies hardware >>>>>so I prefer to hear an answer directly from Hsu. >>>> >>>>I agree. But _I_ don't claiam _anything_ except that members of the DB team >>>>specifically told me that 12(6) means 12 plies in hardware, 6 in software. I >>>>even posted the excerpt from the email that specifically said this... >>>> >>>>That is _all_ I have said about it... >>>> >>> >>>No matter what they say, even under extreme theoretical conditions it is >>>*impossible* to search 18 plies of brute force in chess, without any type of >>>forward pruning whatsoever, and no hash tables. >> >> >>However, they have _never_ said they didn't use forward pruning. They have only >>said "we don't use null-move for forward pruning" and nothing else. And they >>have >>slowly leaked details. But they pretty much had to since I had gone over their >>log >>files and discovered that theyt had a _very_ good branching factor, too good for >>pure >>alpha/beta alone... >> > >Interesting... What was the average branching factor based on the logs you >reviewed? > > I don't remember the _exact_ number although I posted it here in CCC and several were involved in a long discussion about it.. but the number was something less than 4.0 I believe, which is _way_ below what a pure alpha/beta program can produce. > >> >> >>> >>> >>> >>>> >>>> >>>> >>>>> >>>>>> >>>>>>reporting a 12.2 average search depth fullwidth. >>>>>>I guess you never searched with a decent program fullwidth >>>>>>with extensions. If you did, you would understand that >>>>>>getting 12.2 ply fullwidth with loads of extensions is already nearly >>>>>>impossible. Every extended line is searched to the full depth, >>>>>>no pruning happens! >>>>> >>>>>I agree that 12.2 plies with a lot of extensions and no pruning is impossible >>>>>for normal programs and also is impossible for deep blue in case that >>>>>there were real 6 more plies in the hardware. >>>>> >>>>>The only case when it may be possible is if the 6 more plies in the hardware are >>>>>real selective search and it means more pruning than null move with R=3 and in >>>>>this case the 6 plies in the hardware may be eqvivalent to only 2 plies in >>>>>software because of big probability to miss things. >>>>> >>>>>> >>>>>>The interesting 2 questions are >>>>>> a) did DB use 'no-progress pruning' in SOFTWARE (we know >>>>>> already it used it in hardware). >>>>> >>>>>They explained in the article that they did not want to take risks of missing >>>>>something in the first plies so it is clear that they did no pruning in the >>>>>first 12 plies. >>>>> >>>>>If they did some pruning in the software it is clearly after it. >>>>> >>>>>I do not know what is exactly no progress pruning. >>>>>Is there a difference between it and null move pruning? >>>>> >>>>>Is no progress pruning more aggresive than null move pruning? >>>>> >>>>>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.