Author: Robert Hyatt
Date: 07:44:22 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. >(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 This is an idea I published years ago. Cray Blitz used it, and Crafty does also. I called it the "look left - look right_ algorithm. The idea is to not castle one way if it is safer to castle the other way, but it is too deep to see that you _can_. I got the idea from (I think) Lasker, who said "Castle if you want to, or if you must, but _not_ just because you can." Too many times programs castle right into a disrupted king position when waiting a few moves would find the king in a safer "home"... > >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.