Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Chris question

Author: Russell Reagan

Date: 23:11:11 11/21/03

Go up one level in this thread


On November 21, 2003 at 23:05:38, K. Burcham wrote:

>If we are in a tournament with another program why would it ever clear its hash
>during the game? it would seem this would be valuable information for the
>search.

Some programs do different things depending upon the type of the position on the
board.

I remember Johan (TheKing, of Chessmaster fame) saying that he changes the
evaluation a little bit if the fifty move counter gets higher than some number
(I think it was 10, but that's unimportant). This would mean that for the same
position with a different fifty move counter, the score could be drastically
different in his program, so it might be better for him to clear the table after
each move.

The basic idea is that a program can assign different scores to the (almost)
same position, and that can cause problems sometimes. I don't know of anyone who
adds the fifty move counter into their hash key. In TheKing two positions that
have a different fifty move counter, but are otherwise the same, could have
drastically different scores (one with a high fifty move counter could have a
score of close to 0.00 for a draw, while the same position with a low fifty move
counter could be +5.00).

He gave some reasons for why it is beneficial to clear the table. There are good
reasons not to clear it too. The correct choice depends a lot on how the program
works.

Below are Johan's reasons why it could be beneficial to not clear the hash
table.

http://www.chess-archive.com/ccc.php?art_id=311180

>What are the other good reasons for clearing TTs?

1. Predictability
IMHO an engine should just search when a search is needed.
After all it is a tool, not a living creature.

2. Reproducibility
Playing and watching games is the best way to spot funny behaviour.
Not being able to find the cause of this behaviour is pretty frustrating and
may leave unintended features unnoticed.

3. Complexity
Sticky TT requires more data and more code (= more bugs).
Complexity is not a big deal once you've got it right and you're not ever
going to (want to) change things. But that's theory.

4. Preprocessor
A change of the root position might render all TT entries invalid.
Though preprocessing is not as important as it was in the 1980s, I bet most
engines compile at least wood and placement tables based on the game stage
of the root position.

5. Pondering
If an engine has pondered the wrong move, the TT will be overwritten with
positions that are either useless or have the wrong bound.

6. Time management
Admittedly implementation dependent, but the stability of the root (drops,
move changes) is useful infomation. The time manager may get confused if
this information is lost.

7. Unforeseen problems
Eg the perpetual mate that started this thread. Rather funny actually, if it
happens to someone elses engine. But more importantly, rather instructive.
Besides the infamous incomplete-EGDB-problem we now have the infamous
incomplete-TT-problem. :-)

... Johan



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.