Author: Robert Hyatt
Date: 07:30:22 01/29/00
Go up one level in this thread
On January 29, 2000 at 00:57:01, Christophe Theron wrote: >On January 28, 2000 at 23:54:06, Robert Hyatt wrote: > >>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... > > >We are not that far away, Bob... Take a look at how deep Fritz is searching on >tournament level... During the WCCC I have also seen Shredder and Nimzo reaching >some high depths. > >Of course the depth is not the same kind of depth, but still... > > > Christophe I see depths of 13-14 regularly in the middlegame. But I am using null-move with R=3/R=2. So far as I know, DB didn't resort to this... I would trust a 17 ply search without null-move _far_ more than a 17 ply search with null-move. Much less 17 without to 12-13-14 with... And fritz doesn't do SE...
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.