bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] Tutor Mode/Hint question


From: Jim Segrave
Subject: Re: [Bug-gnubg] Tutor Mode/Hint question
Date: Fri, 10 Jan 2003 16:02:20 +0100
User-agent: Mutt/1.4i

On Fri 10 Jan 2003 (13:31 +0000), Joern Thyssen wrote:
> 
> It's a known problem that tutor mode re-evaluates the moves a second
> time. It's a general problem with the analysis code, so the same problem
> exists if you re-analyse a match.
> 
> It's on my TODO list to fix this, but unfortunately it's not entirely
> trivial, because we only save the highest evaluation for each move, but
> the move filters requires us to evaluate all moves on 0-ply, then some
> of those on 1-ply, the some of those on 2-ply etc etc. For example, a
> sample chequerplay decision has 4 moves evaluated on 2-ply, another 6
> moves on 1-ply, and the remaining 37 moves on 0-ply. Assume I want to
> re-analyse this move (possibly with another move filter). How should I
> do this? The biggest problem is that move filters involves comparing
> equities, but you cannot compare 2-ply equities with 1-ply equities as
> this is like comparing oranges and apples :-)
> 
> I've a number of strategies for this. Two main points are:
> 
> (a) avoid re-doing any, possibly expensive, re-evaluations
> (b) consistent results, i.e., no difference between re-analysis of a
>     move (possibly with a new move filter) and first analysis with a given
>     move filter.
> 
> Unfortunately (a) is orthogonal to (b), so we have to decide which
> approach to take. As a exact-science scientist I prefer that (b) is
> fulfilled, however, as an impatient user I prefer that (a) is
> fulfilled.

Cacheing?

Suppose that we cache evaluations with keys of positionID and no. of
plies only (where a rollout evaluation could be given an arbitrarily
large no of plies so that it's always taken as the best one). Entries
could be reused in LRU order, so recent evaluations are kept as long
as possible.

Any change made to move filters or other settings which could affect
an evaluation invalidates all cache entries. The cache could have
associated with it a copy of the relevant settings which apply to its
contents. This need not be checked on every cache access, instead it
needs only to be checked when a command is executed that may lead to
evaluations being done - Evaluate, Analyse, Hint, Rollout would cover
it. 

For things like tutor mode or use of the hint window, I would expect
that for reasonable cache sizes, that the delay would be minimal to
re-analyse, as the evaluation results for all the intermediate
calculations would still all be in the cache. 

I wouldn't expect to be able to change the analysis settings and not
have to wait while a move, match, or game is re-evaluated seems
reasonable.

How big does the cache have to be? I'm running a profiler on a 376
move 7 game match, which will give me call counts. From that I should
be able to get an average no. of evaluations/move. If I assume
(hand-waving mode on) that the worst case is 20 to 50 times as many
evaluations as an average one, I'll have some estimates.

-- 
Jim Segrave           address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]