Author: Rolf Tueschen
Date: 03:51:03 10/08/02
Go up one level in this thread
On October 08, 2002 at 00:52:38, Eugene Nalimov wrote: >Wrong. > >Today I visited the talk by Feng-Hsiung Hsu he gave at Microsoft. Here are some >points from memory: > >They used forward pruning in the hardware, and according to Hsu it gives them >5x-10x speedup. He wrote about that in the book, too, but without any details. >In the talk he named that pruning as "analogy cutoff" and mentioned that "if the >move is useless in some position, it is also useless in the similar position". >In the book he writes "it can be done in the hardware as long as it does not >have to be 100% correct". > >They used null-move thread detection, as well as not only singular extension, >but also extension on only 2 or 3 good replies. They used fractional extensions. >He also says that their Q-search is much more powerful than the one that is >usually used in the software-only programs. > >Hsu gave some details why they don't use null-move: >(1) He thinks that singular extensions and null-move gave more-or-less the same >rating difference (100-200 points IIRC). Null move allows you to search 3-4 >plies deeper *everywhere*, but Hsu thinks that they have enough depth. He thinks >that on the highest level it's absolutely necessary to analyze critical lines >*much* deeper, and singular extensions do exactly that. >(2) It's very hard to implement both null move and singular extensions in the >same program. >(3) When they played commercial programs that use null-move those programs >regularly played themselves into zugzwang [by first pushing bad events over the >horizon], and Hsu thinks that is direct result of the using null move. > >When asked by Tom, Hsu gave 2 examples of the search terms that are very >expensive to evaluate: >(1) Rooks on open file -- when they tried to analyze super-GM games, it looks >that those GMs value rooks on the open file much less that usually thought. It >happened that you need not only rook on the open file, you also need to be able >control 7-th and 8-th rank (or is it file? sorry for my English). To properly >calculate "will you control those ranks or not" you need lot of computing power. Eugene, Bob and to whom it may concern: that paragraphe - if it gives a good reflection of Hsu's thought process - shows to me at least, and I am not a GM by far, that Hsu can't be taken too serious. (Well, what you might think about me in the first instance.) Look, what he's talking about is perhaps for MICROSOFT engineers the hype of chess sophistication, so from a layman's view, in German we say from a frog's perspective. Hsu is trying to imply that they had all that under control or at least were aware of. Well, he can be lucky that he hadn't to play Kramnik. Because that exactly is the art of such GM (I must mention here Bobby Fischer as the perhaps most outstanding example for the discovery of the most hidden concreteness of a position, just take Rf6 in one of the US-ch games against Benkö) that they are able to judge if here it's better to play Rad1 or Rfd1, just to give you an example. Hsu is reveiling a low understanding of chess if he's presenting such importances of depth. We could say that depth is _always_ the judge in a situation. Just take Kramnik's second game. The moment Black had the pawn on a5 Kramnik knew that if he could hold the initiative that he could hold Ra8 as a hostage. The rest is also chess but no longer decisive for the outcome - in case you can master all the technique problems. For me, without being a programmer, it seems impossible to get to the important depths with nullmove. Because as I've understood the horizon would be extended if something awfull could be seen. But this way you can't get near to certainty in the starting position. And because each detail is changing the judgement you are forced to calculate it all through to the end. But what will you do if this takes too long in a tournament game? Anyway, a good human player would nail you into the wall right here when he can foresee that such things can't be done by the machine. Most decisions in real chess have those in depth crucial decision points. And they all depend on the very concreteness of the position. Rolf Tueschen >(2) King safety -- before castling they calculated 3 values (center, left, and >right positions after castling), and to properly calculate control over those >squares you need lot of power. > >[Note: here I disagree with Tom. Yes, those calculations can be done in the >software, but assuming that there are ~20 such factors, and each slows the >software search by ~10-20%, resulting 3x slowdown looks too much for me]. > >Thanks, >Eugene > >On October 07, 2002 at 10:05:27, Gian-Carlo Pascutto wrote: > >>On October 06, 2002 at 21:21:17, Robert Hyatt wrote: >> >>>Lack of null-move is not a known deficiency. I can name a pretty successful >>>program >>>or two (commercial) that didn't rely on it... >> >>They use other ways of forward pruning that replace nullmove. The DB >>team did nothing of that sorts. >> >>-- >>GCP
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.