bug-gnubg
[Top][All Lists]
Advanced

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

Re: Bug-gnubg Digest, Vol 244, Issue 8


From: Joseph Heled
Subject: Re: Bug-gnubg Digest, Vol 244, Issue 8
Date: Tue, 25 Jun 2024 06:07:42 +1200

Move filters are very tricky. 
I am pretty sure the testing I did 20+ years ago, when I developed them, should be repeated with the current net and taking the huge advance in cpu speed into account.

-Joseph
  

On Tue, 25 Jun 2024 at 05:30, Frank Berger <frank@bgblitz.com> wrote:
Hi all,

> eval evaluates the current position only, not the possible checker plays
> or cube action, so the move filter is irrelevant. The evaluation is done
> at the ply level you asked.
well at +1 ply you could evaluate more than the best move as well, only due that BG has much better evaluation function than chess we can do that :)

> The best move is clear enough that there are no other "moves within
> equity 0.16" and the evaluation stops at 0 ply.
Ah, ok, that explains the behaviour. I feel it is a bit surprising, getting 0-ply when asking for 2-ply but that surely makes sense performancewise.

>
> Moves 2 and 3 are now close enough at 0 ply to be evaluated more deeply.
>
> Another possibility is to raise n in the "keep the first <n> 0-ply
> moves". It probably makes sense only for analysis or hint, not for
> actual play or rollouts.
It costs a lot of time and only rarely finds a better move. I did this earlier and removed it for exactly that reasons.

>
> But in this case a good value for n is not obvious. 1 is dubious and
> could lead to issues like in
> https://www.bgonline.org/forums/webbbs_config.pl?read=213668
>
> Then how much? 2? More? Something somehow correlated to the "more moves
> within equity" parameters?
I completely agree, a wide filter is probably the better solution.

Thanks for your response.

best
Frank

reply via email to

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