When gnubg evaluates a play it throws away the existing evaluation (and/or
rollout) for that play (ignoring the cache). This seems desirable,
otherwise the .sgf file would be large.
For example, consider the pre-defined "world class" move filter. Gnubg
analyzes up to 8 plays within .16. For a given position, suppose that
gnubg analyzes 4 plays (A, B, C, D) at 2-ply. Now, suppose that you want
to redo the analysis using supremo. You can't do it without first
re-analyzing A, B, C, and D at 0-ply (the supremo move filter says to
analyze up to 16 plays within .32, using 0-ply evaluations to determine
whether a play is within .32 of the best 0-ply play). These 0-ply
evaluations may still be in the cache (I don't know precisely what
evaluations are stored in the cache), but they won't be there if you save
the .sgf file and open it again in a new gnubg for example (plays A, B, C,
and D will only have 2-ply evaluations in the .sgf file).
Snowie doesn't throw away lower-ply evaluations (or rollout
information). It keeps all the information in the file, allowing the file
to grow large. For example, if you select 20 plays, evaluate all of them
at 3-ply, then re-evaluate them at 1-ply, then re-evaluate them all at
3-ply again, these last 3-ply evaluations will all display
instantly. Similarly, if you roll them all out, you can cycle between
1-ply, 3-ply, and rollout displays instantly (Snowie doesn't have to take
time to re-evaluate or re-rollout).
Chris
At 04:52 AM 9/3/2009, Michael Depreli wrote:
I checked to see how Snowie 3 handles the "outside the new filter issue".
After reanalysis it drops the moves down to the level it would have been
had the larger filter been
run in the first place. At least that way it's consistent.
How come if gnubg has the analysis already stored from the narrower
filters it simply just can't analyse
any NEW moves that fall within the wider filters? It doesn't need to
reanalyze the others.
> Date: Thu, 3 Sep 2009 00:14:10 +0200
> Subject: Re: [Bug-gnubg] FW: Analysis Question
> From: [email protected]
> To: [email protected]
> CC: [email protected]; [email protected]
>
> Wouldn't work. Suppose that you have a half made analysis and then
> restart it. Since the move filter is not stored you would have to go
> through the match and re-analyse at plies N-1 to make sure that all
> moves are within the current filter. Time lost. And suppose that you
> some moves are now outside the new filter. Should they then be
> dropped?
>
> I guess that with a lot of jumping through hoops we could make this
> work and half way consistent, but is it really worth it? What we do
> now is at least consistent.
>
> Christian.
>
> On Wed, Sep 2, 2009 at 11:22 PM, Michael Petch<[email protected]>
wrote:
> >
> > I've been asked this by others. Personally I'm not sure I would
change how
> > it operates. If one knows this, its just as easy to clear the
analysis and
> > redo it. Just an opinion
> >
> > ------ Forwarded Message
> > From: "[email protected]" <[email protected]>
> > Date: Wed, 2 Sep 2009 12:39:12 +0000
> > To: Michael Petch <[email protected]>
> > Subject: Analysis Question
> >
> > Hi Michael
> > I part analyzed a match then stopped it as I wanted to increase the move
> > filters.
> > Saved settings and re-ran the analysis.
> > Gnubg only analyzes at the larger filters from where the previous
analysis
> > finished.
> > Is there a reason for this?
> > Obviously it would be good if it added analysis for the extra moves
included
> > with the wider filters.
> >
_______________________________________________
Bug-gnubg mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnubg
