Author: Robert Hyatt
Date: 18:19:36 05/24/98
Go up one level in this thread
On May 24, 1998 at 18:56:16, James B. Shearer wrote: >On May 18, 1998 at 16:23:33, Thorsten Czub wrote: > >>Why is it important to win the race with the fast >searchers in a field >>that is their advabtage by definition. >>They are pretty good in finding. We all know this. >But this is - like a >>famous banned programmer would say - bean counting >! > > I don't understand your point of view. Your >favorite program is called CSTal not CSPetrosian. >It is my understanding that, like Tal, it plays for >sharp tactical positions. So how can you argue that >it is not important that other programs handle such >positions better? > Thorsten Czub also wrote: >>When there is NOTHING to measure, than the strength >of the speculative >>programs appears. in 80 % of all chess positions >where there is NOTHING >>to force out. > > If you are much weaker tactically than your >opponent, there may not be anything for you to find >but there will be plenty for your opponent to find. >One tactical blunder every five moves (20%) will not >win many games against a "finder". > James B. Shearer this is really not worth discussing. Thorsten/Chris/others have one frame of reference: "knowledge is the only important thing, if a program doesn't 'do it like a human' then that program is not worthy of anything". That "frame of reference" has been around since the early days of computer chess. There's nothing "wrong" with it, except, that over the past 20 years it hasn't worked *yet*. It may in the future, but it hasn't to date. The other perspective is a fast program, with reasonable pieces of knowledge, and reasonable search extensions. Those programs have proven their superiority since 1976 when chess 4.0 proved that selective search wasn't the only way to win games... And everyone pretty well followed their lead for the next 20+ years. My opinion is somewhere in the middle. There are two parts to a chess playing entity... static evaluation and dynamic evaluation. Static evaluation is what most programs do to evaluate a "quiet" position... things like pawn structure, king safety, piece placement, and can even consider some dynamic qualities like piece interaction and so forth. Dynamic knowledge seems (at present) to be best handled via a tree-search, at least that has been the best approach so far. It is responsible for shuffling pieces around to reach positions that the static evaluator can handle with few or no errors. The better the search meets this goal, the better the program plays. The question is, can search find quiet positions or must the evaluator handle non-quiet positions. I believe the search can accomplish this... folks like Chris don't and try to evaluate dynamic stuff instead. Nothing says that approach is wrong... but there is plenty to suggest that it hasn't worked well to date... And don't forget... *everyone* is depending on the search to some extent, which is an admission that an evaluation function can't do it all... I'm going to continue my approach... adding new search extensions, adding more knowledge when I hit something that search simply can't handle, and I'm sure Chris is going to continue his approach, doing everything in eval and only relying on search as a last resort. Which will be better? Today, the answer is obvious. Next year, who knows. I see *nothing* to say that either approach can't produce an electronic GM. The main advantage is that at present, my approach does it with a lot less code... which, for the time being, I like. I've done selective. I converted to full-width + extensions in 1978. I won't change back without really convincing evidence that it is the right way to go... And I'm not going to hold a strong prejudice against those programs that take alternative approaches, so long as they show that they can produce reasonable results against strong humans *and* strong programs from both camps...
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.