Author: Robert Hyatt
Date: 20:54:06 01/28/00
Go up one level in this thread
On January 28, 2000 at 23:50:45, Robert Hyatt wrote: >On January 28, 2000 at 17:35:56, Robert Hyatt wrote: > >>On January 28, 2000 at 10:50:40, Dave Gomboc wrote: >> >>>On January 28, 2000 at 04:12:38, Jeremiah Penery wrote: >>> >>>>On January 28, 2000 at 01:35:20, Dave Gomboc wrote: >>>> >>>>>On January 27, 2000 at 21:20:46, Christophe Theron wrote: >>>>> >>>>>>On January 27, 2000 at 14:21:19, Dave Gomboc wrote: >>>>>> >>>>>>>On January 27, 2000 at 13:00:39, Christophe Theron wrote: >>>>>>> >>>>>>>>On January 27, 2000 at 00:06:19, Dave Gomboc wrote: >>>>>>>> >>>>>>>>>On January 25, 2000 at 21:26:19, Christophe Theron wrote: >>>>>>>>> >>>>>>>>>>On January 25, 2000 at 13:33:36, Dave Gomboc wrote: >>>>>>>>>> >>>>>>>>>>>It seems weird to me that when Ed Schroder says Rebel does better without >>>>>>>>>>>null-move than with it, people believe it, but people criticize the DB team for >>>>>>>>>>>not using it (e.g. from your text above: "by not using a good, known pruning >>>>>>>>>>>system..."). >>>>>>>>>> >>>>>>>>>>If the DB team did not have enough time, they could simply take the null move >>>>>>>>>>algorithm because there is documentation available on it. >>>>>>>>>> >>>>>>>>>>However null move is not the final say. Rebel does very well with ANOTHER >>>>>>>>>>pruning system. Junior does very well with ANOTHER pruning system as well. And >>>>>>>>>>there are other programs that do fine without null move, one of which I know >>>>>>>>>>very well. >>>>>>>>> >>>>>>>>>Yes, and DB does very well with ANOTHER pruning system too. What's your point? >>>>>>>>> >>>>>>>>>Dave >>>>>>>> >>>>>>>> >>>>>>>>My point is that they claimed that they did not use one. Several of us, looking >>>>>>>>at the apparent branching factor shown in the DB log files, have doubts about >>>>>>>>this. >>>>>>>> >>>>>>>> >>>>>>>> Christophe >>>>>>> >>>>>>>Where did they claim that they did not use one? In their published work they >>>>>>>clearly stated the contrary. >>>>>>> >>>>>>>Dave >>>>>> >>>>>> >>>>>>What did they say? >>>>>> >>>>>> >>>>>> Christophe >>>>> >>>>>Argh, I can't find the paper! >>>>> >>>>>In the software, there are some full-width plies, then some selective plies. In >>>>>the hardware, there are some full-width plies again. >>>>> >>>>>That is from memory though. >>>>> >>>>>Maybe Ernst can pull out his copy of Search Control in Deep Blue? >>>> >>>>I think the 'selective plies' are the extensions. The full-width plies at the >>>>end of the search, in hardware, coincide more with the evaluation function than >>>>anything. Rather than doing a static evaluation at the end of the search, they >>>>did that evaluation based on a 4-ply search done in hardware, to lessen any >>>>error involved. >>> >>>That was not the impression I got from reading the article. Normally when one >>>speaks of selective plies one speaks of pruning some moves out. I'm not saying >>>that they're not extending some lines like crazy, though. >>> >>>Also, the hardware didn't have to do a 4-ply search. It was configurable. >>>Looking at the logs, where you can clearly see the (3), (4), (5), (6) after the >>>plies, it makes me want to guess that the number inside the brackets is the >>>full-width depth that the hardware searched. But that's just speculation. >>> >>>Dave >> >> >>No.. that I know didn't happen. I can explain the technical details but they >>are messy.. but the deal is that the chess hardware has a pretty narrow range >>of depths it can search to without (a) searching too quickly for the SP to >>keep it busy or (b) searching so slowly that the SP is waiting all the time >>and not helping. >> >>Hsu settled on 4 and stuck with it so far as I know, although it is possible >>this was bumped up in endgames (I haven't seen anything suggesting that it was >>however...) > > >My guess was wrong. From the DT team, the number _is_ the hardware depth. >In deep thought, it apparently could vary from roughly 3 to 5 depending on >whatever, although the shallower the better, since there was no hashing in >the hardware and the resulting search trees would get bigger quickly. > >But now the actual search depth should be treated as the sum of the two >numbers, something we didn't know for certain before. Just looked. And this gadget is beginning to look even more frightening that I first thought. Typical software search depth was 10, and at that depth the hardware depth always seemed to be 6. For a total depth of 16 plies, which is a monster. Many searches were 11/6 or 17 plies. Think about that in the concept of todays micro programs... that is scarey...
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.