Author: Robert Hyatt
Date: 09:06:36 12/06/01
Go up one level in this thread
On December 05, 2001 at 14:53:34, Uri Blass wrote: >On December 05, 2001 at 14:15:59, Robert Hyatt wrote: > >>On December 05, 2001 at 03:12:49, Russell Reagan wrote: >> >>>If I run any top chess program, eventually the program doesn't get any new best >>>move. Is this because the next ply is simply taking too long, or is it because >>>the engine isn't designed to do searches for long periods of time (like days or >>>weeks)? >>> >>>In other words, is it possible to write a program that is better suited for >>>searching to deeper depths if it were given, say, 1 year to search for the best >>>move? Or are current algorithms about as good as we're going to get in long term >>>analysis? >>> >>>Another way of phrasing this would be: Is there any difference between a program >>>designed to analyze completed games over long periods of time and a program that >>>plays chess at a shorter time interval? >> >> >>A program "hits the wall" for various reasons. The most common is that once >>you totally saturate the hash table, move ordering starts to break down and >>the effective branching factor grows. > > >I do not think that the effective branching factor of Deep Fritz grows at long >time controls. It _must_. To see how bad it can get, disable hashing completely and check the branching factor. Since that is the critical path to passing good moves around in the search for move ordering, doing without it is a killer. And for very deep searches, you _must_ run into this problem because the hash table size is tiny compared to the tree size for a 3-day search. IE at 1M nodes per second, you will search about 260 trillion nodes in 3 days. With 2 gigs of memory, you will have about 128 million hash entries. you can only store roughly .05% of the stuff you search, which means you will effectively be searching with no hash table in lots of sub-trees. > >one of the reason that I prefered Deep Fritz and not other programs for long >analysis is the fact that Deep Fritz knows to count knodes correctly even when >the number of nodes is bigger than 2^32 > >I remember thar I read that Crafty is using the number of nodes for order of >moves so it is a reason not to use it for long analysis because the order of >moves at big depth may become wrong. It only does this at the ply-1 move list between iterations. It is going to take a long search to make some of the ply-2 moves go beyond 4 billion nodes each to screw the ordering up. And the "best move" _always_ goes first no matter what the node count. > >I was also afraid that other programs that do not know to count nodes correctly >may have problems at long time control as a result of not knowing to count nodes >correctly. Some programs don't even count 'em as it is not important. IE Belle and Deep Thought/Deep Blue didn't have any way to count nodes. > >The only program that I can trust for long time control except Deep Fritz is >Tiger because I remember that Christophe said that he does not use the number of >nodes for order of moves. > >Uri This really doesn't matter. If you finish an iteration, you will search _all_ moves at the root, even if one is out of order due to an overflow in node count. Won't produce a wrong answer or anything else...
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.