Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Neverending story with incomplete tablebases

Author: Uri Blass

Date: 02:08:58 08/16/03

Go up one level in this thread


On August 16, 2003 at 04:47:34, Johan de Koning wrote:

>On August 15, 2003 at 17:50:28, Robin Smith wrote:
>
>>On August 14, 2003 at 02:51:36, Johan de Koning wrote:
>>
>>>On August 13, 2003 at 17:53:30, Dieter Buerssner wrote:
>>>
>>>>On August 13, 2003 at 03:00:10, Johan de Koning wrote:
>>>>
>>>>>On August 10, 2003 at 13:57:00, Amir Ban wrote:
>>>>>>The log doesn't show what J8 was thinking. Apparently it thought it was mating ,
>>>>>>because it played all moves in 0 seconds.
>>>>>
>>>>>Yet another good reason to clear out the TT at the start of every search!
>>>>>:-)
>>>>
>>>>Or to use the time to find a shorter mate, even when seeing a mate already.
>>>
>>>Indeed, but that didn't suit my point. :-)
>>>
>>>>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
>>
>>Johan,
>>
>>For someone who uses chess engines to do analysis, rather than just playing
>>games, clearing Ttables is a serious flaw.
>
>Remembering partial analysises randomly is also a serious flaw.
>User control is the keyword I think.
>
>... Johan

Yace does not remember them randomely and I believe that after every search it
remembers a small list of position, move,depth and score in order to use that
information later.

I think that the best learning for the user may be only to remember this
information.

The idea is that if you analyze the position after 1.e4 to depth 15 and find
score of 0.12 pawns for white and main line 1...e5 2.Nf3,.... then when you go
back you want to save the analysis of 1.e4 in the first 16 plies and return
score of 0.12 pawns for white
if you do not find something better than e4.

You can remember the following information

opening position,    depth 16,move e4, score 0,12 for white
position after e4,   depth 15,move e5, score 0.12 for white
position after e4 e5 depth 14,move Nf3,score 0.12 for white

It is not important in the opening position but important when there is many
forced lines and you want the engine to analyze and learn from previous analysis
of the forced lines when you go forward and backward with it.

Note that you can clear the big hash tables and still remember this information.

You can check for every position that you get in the search if it is in the list
of the small table that you have and in case that it is and the remaining depth
is small enough you can save the search.

It is possible to do it even if you have a root processor and in this case the
user can be allowed to tell the engine to analyze all the positions based on
specific root position so you do not get problems of
comparing apples with oranges when the 0.12 for white is misleading because you
moved to another position.

Uri



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.