Author: John Reynolds
Date: 09:00:49 06/15/02
Go up one level in this thread
On June 15, 2002 at 11:36:29, Christophe Theron wrote: >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 Watch it Chris! you may be revealing Secrets here.
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.