Author: Russell Reagan
Date: 14:34:17 07/24/03
Go up one level in this thread
On July 24, 2003 at 15:09:58, Steve Maughan wrote: >>As you well know, at each move the position is setup'ed again. >>Normally this will clear hash-, killer- an historytables. > >With respect this is nonesense. There is no reason at all to clear the hash, >killer or historytable just because you're under UCI. Monarch doesn't and I >doubt Shredder, YACE or Sjeng do either. Perhaps I am just inexperienced compared to you when it comes to transposition tables, but it seems like there would be a good reason to clear the transposition table when you start a new game or start analyzing an unrelated position. Correct me if I'm overlooking something important. Let's say that I use a single table and I replace using the "depth preferred" method. I let my engine analyze overnight on an endgame position, and my table is now filled with entries of 20 ply or more. I wake up the next morning, note the analysis results, and decide to analyze a complicated middlegame position, in which it gets to only (say) 13 ply after another overnight analysis. Wouldn't my transposition table be completely useless then, since not one single element would get written to it? Even if you use two tables of "depth preferred" and "always replace", you're wasting the depth preferred table. From this example, it seems like a good idea to clear the hash table when you setup a new position (either via FEN/EPD or a new game). There might also be issues with an engine that does preprocessing (maybe it looks at the position and then calls different search or evaluation routines based upon the specifics of the position). I think an engine should be able to know if positions are related or not. Under the winboard protocol, if my engine recieves a "setboard" or "new" command, I can assume the position is unrelated to the one I was just working with. Under UCI you really have no way of knowing unless you want to add extra code to detect whether the new position is related to the old one, but then all of the sudden UCI isn't so easy to implement, which is one of its advantages. This seems to be the main drawback of UCI, that it assumes that chess engines all work the same way. 99% of them are very similar, but I just don't think that's a good design when it assumes things like that. Modularity and encapsulation are good things IMO, and a communication protocol should have those qualities. The Winboard protocol has good ideas, and the UCI protocol has good ideas, but maybe it is time for something new that address the shortcomings of both protocols.
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.