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 <[email protected]> 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
>
  • Re: Bug-gnubg... Frank Berger
    • Re: Bug-... Joseph Heled
      • Move... Philippe Michel
        • ... Joseph Heled
          • ... Philippe Michel
            • ... Joseph Heled
              • ... Philippe Michel
                • ... Bug reports for and general discussion about GNU Backgammon.

Reply via email to