bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] more on movefilters


From: Joern Thyssen
Subject: Re: [Bug-gnubg] more on movefilters
Date: Thu, 12 Dec 2002 11:35:46 +0000
User-agent: Mutt/1.4i

On Thu, Dec 12, 2002 at 11:55:14AM +0100, Øystein O Johansen wrote
> 
> > Hi all,
> 
> Hi Jørn!
> 
> > I like the new movefilters, however, I think we should
> > have one set of movefilters for hint and another set
> > for analysis (and possibly a third set for gnubg's play).
> 
> Sure, I also like the movefilters. It's so much more
> general.
> 
> > For example, I might play against gnubg with a rather
> > small search space, but analyse the match with a larger
> > search space. It's a bit annoying having to change back
> > and forth.
> 
> Sure.
> 
> > We may even generalise this to having a set of
> > movefilters for each
> >
> > "set .... chequerplay" command.
> 
> Isn't it quit easy to add a movfilter to each EvalContext?
> movefilter as a member of the struct? The command will then
> be:
> 
> set eval chequerplay evaluate movefilter 1 0 0 0
> set analysis chequerplay evaluate movefilter 1 0 0 0

I would rather *not* have the movefilter inside the evalcontext. I'm
quite happy that the search space is gone, since the search space has
nothing to do with the evaluation. 

Also, as you note, movefilters are meaningless for cube decisions. The
current evalcontext contanis evaluation parameters only: number of
plies, cubeful flag, reduced evaluation, and noise parameters. 

For example, the movefilter belongs in the movenormal record, not in
each individual evaluation of the possible moves.

I'll do anothing to keep the movefilters away from evalcontext!!!! ;o)

I prefer 

set eval chequerplay evaluation plies 2
set eval chequerplay movefilter 1 0 0 0 

and

set eval chequerplay evaluation plies 2
set analysis chequerplay movefilter 1 0 0 0

Jørn



reply via email to

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