Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Crafty modified to Deep Blue - Crafty needs testers to produce outputs

Author: Bas Hamstra

Date: 13:32:01 06/18/01

Go up one level in this thread


On June 18, 2001 at 11:57:41, Ulrich Tuerke wrote:

>On June 18, 2001 at 11:19:41, Bas Hamstra wrote:
>
>>On June 18, 2001 at 10:40:55, Ulrich Tuerke wrote:
>>
>>>On June 18, 2001 at 10:25:36, Uri Blass wrote:
>>>
>>>>On June 18, 2001 at 10:01:45, Ulrich Tuerke wrote:
>>>>
>>>>>On June 18, 2001 at 08:54:10, Uri Blass wrote:
>>>>>
>>>>>>On June 18, 2001 at 08:33:21, Ulrich Tuerke wrote:
>>>>>>
>>>>>>>On June 18, 2001 at 08:28:08, Bas Hamstra wrote:
>>>>>>>
>>>>>>>>On June 17, 2001 at 01:09:50, Robert Hyatt wrote:
>>>>>>>>
>>>>>>>>>On June 16, 2001 at 22:59:06, Vincent Diepeveen wrote:
>>>>>>>>>
>>>>>>>>>>Hello,
>>>>>>>>>>
>>>>>>>>>>From Gian-Carlo i received tonight a cool version of crafty 18.10,
>>>>>>>>>>namely a modified version of crafty. The modification was that it
>>>>>>>>>>is using a small sense of Singular extensions, using a 'moreland'
>>>>>>>>>>implementation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>Instead of modifying Crafty to simulate Deep Blue, why didn't you
>>>>>>>>>modify Netscape?  Or anything else?  I don't see _any_  point in
>>>>>>>>>taking a very fishy version of crafty and trying to conclude _anything_
>>>>>>>>>about deep blue from it...
>>>>>>>>>
>>>>>>>>>Unless you are into counting chickens to forecast weather, or something
>>>>>>>>>else...
>>>>>>>>
>>>>>>>>I don't agree here. It is fun. Maybe not extremely accurate, but it says
>>>>>>>>*something* about the efficiency of their search, which I believe is horrible. I
>>>>>>>>think using SE and not nullmove is *inefficient* as compared to nullmove. We
>>>>>>>>don't need 100.0000% accurate data when it's obviously an order of magnitude
>>>>>>>>more inefficient.
>>>>>>>
>>>>>>>May be you are right, if the program is running on a PC. However if you can
>>>>>>>reach a huge depth anyway because of hardware, may be you can afford to use
>>>>>>>this, because it doesn't matter too much wasting one ply depth ?
>>>>>>
>>>>>>It is not about wasting one ply but about clearly more than it and
>>>>>>it is clear that not using null move is counter productive when the difference
>>>>>>becomes bigger and not smaller at longer time control so the fact that they had
>>>>>>better hardware only supports using null move.
>>>>>
>>>>>How can you be so sure ? Do you really know that all of the top programs are
>>>>>using null move. I wouldn't bet too high on this. There may be viable
>>>>>alternatives to this, though not being published.
>>>>
>>>>I know that Junior and Rebel do not use null move but they use other pruning
>>>>techniques.
>>>>
>>>>I do not believe that the technique of no pruning+singular extension is good at
>>>>long time control and this is the point.
>>>
>>>You may be right or not. Who knows ?
>>>Who really knows the program of the Deep Blue guys ?
>>>IMHO, the discussion is far too speculative.
>>>
>>>I guess that these gentlemen were knowing very well what they were doing.
>>>I think that it's almost some kind of arrogance, to disqaulify their program
>>>without knowing a thing. Isn't it ?
>>
>>Now you sound exactly like Bob.
>
>Well, may be, he isn't always wrong. -:)
>
>>Noone is disqualifying their program. At the
>>time unbeatable. But it *is* possible to compare search model A with search
>>model B and conclude that B is better. DB is not a magical black box that we
>>know absolutely about. We know they didn't prune. So they could have even been
>>stronger.
>
>I just doubt that the comparison is possible, because they had a completely
>different platform with charactistics being basically different from what we >used to. So, for example, search coasted practically nothing compared to
>evaluation because it was done by hardware. You would have to simulate this >too.For instance, searching an extra ply deeper by use of SE wasn't a big >problem for them. But it may be a problem for a PC program.

I don't see this. If search was free, they had the choice to burn many nodes in
extensions or they could get extra depth. Suppose they had a reasonable qsearch,
then at depth-2 you miss hardly anything. Then they had the choice:

a) Seeing 20 ply positionally, not missing anything up till 18 ply
b) Searching 16 ply and not missing anything, with SE on top of that

That's the situation, and I don't see where DB differs here from a PC program.
To use the standard joke: if A plays B, B sees first that it gets mated :-)

>May be, I'm just a bit stubborn, but I keep on being very sceptical about
>Vincent's approach.

Depends on what he is going to do, I'm not sure. Of course his first post has a
provocative title, but I am interested in some results anyway.


Best regards,
Bas.








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.