Author: Christophe Theron
Date: 21:57:01 01/28/00
Go up one level in this thread
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
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.