Author: Christophe Theron
Date: 08:36:29 06/15/02
Go up one level in this thread
On June 15, 2002 at 00:20:48, Robert Hyatt wrote:
>On June 13, 2002 at 23:58:46, Christophe Theron wrote:
>
>>On June 13, 2002 at 09:13:43, Robert Henry Durrett wrote:
>>
>>>On June 13, 2002 at 06:00:13, Jorge Pichard wrote:
>>>
>>>>Hiarcs 8 was NOT made for slow computer such as an AMD 450 Mhz as the SSDF
>>>>decided to test it against Nimzo 8.
>>>
>>>What, exactly, causes this problem?
>>>
>>>Do other chess engines have this same problem too?
>>>
>>>
>>>Bob D.
>>
>>
>>
>>The problem is that the problem described above does not exist.
>>
>>
>>
>> Christophe
>
>Here we disagree significantly.
>
>One trivial case... Take a program that uses null-move R=2 or 3, and run
>it on a very slow machine. Then on a very fast machine. The slow machine
>will make significant blunders because the R=2 or R=3 depth reduction will
>be a killer. But as the depth increases, the tactical oversights go away
>and the null-move program benefits more from the extra speed than what you
>might see from a non-null-move program.
>
>I watched this happen personally. I almost gave up on R=2 for that very
>reason, until suddenly the P6/200 came along and bumped the depth up enough
>so that suddenly the R=2 or R=3 didn't cause tactical blunders nearly as
>often.
>
>That is but _one_ example. Other obvious cases come to mind. At a specific
>depth, you need some tactical evaluation to avoid blunders. IE if you can't
>search 2 plies, you need to evaluate forks statically. But as the depth
>increases, suddenly the search handles this and doing it in the eval simply
>slows the program down. But not doing it in the eval will kill it on slow
>hardware.
>
>The list goes on and on...
I agree with you on the principle (some changes are needed for a program to
perform not too badly at shallow search depths), but not on the examples you
give.
I think you are basing your remark about null move on impressions. It is true
that you can notice dramatic tactical blunders because of it, but you do not
take into account the number of games where it helped more than it hurt.
You would need to play long matches with some statical reliability to be sure
(and I have done it).
Also, null move as it is done in Crafty has some big weaknesses because of your
QSearch. Your philosophy is that the QSearch should be as fast and simple as
possible, and it amplifies the null move weaknesses.
About the "fork" example: I would not treat it by evaluation. I have tried and
it does not work. The solution of this problem must be found in search or
QSearch improvements.
I know it very well because of all the programmers out there I must be the only
one to have an up to date program targeted to run on both very slow computers
and very fast ones (Chess Tiger and Chess Tiger for Palm share exactly the same
engine code).
Christophe
This page took 0.01 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.