bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Resign bug


From: Joern Thyssen
Subject: Re: [Bug-gnubg] Resign bug
Date: Mon, 18 Aug 2003 13:16:48 +0000
User-agent: Mutt/1.4.1i

On Sun, Aug 17, 2003 at 06:25:34PM -0400, Ric wrote

> Also, note the 12 roll near the end of Bug_move32. Here gnu with a man on
> his ace and a man on his deuce takes only one chequer off. 

I'll jump into the heated discussion as well!

For cubeful chequerplay evaluations gnubg will sort the moves by cubeful
equity and secondarily by cubeless equity if the cubeful equities are
identical. In this case, both the cubeful and cubeless equity are
identical thus gnubg cannot see the difference: it selects an
arbitrary one, which in this case happens to be the annoying (and
provoking on some players) move.

If someone provides a general scoring algorithm that make gnubg make the
least provoking move in these cases then I'll be happy to put in on my
list for future improvements. As I don't see it as a bug it will not get
the top priority. Well, at least not on my list -- other developers may
find this interesting or worthwhile and implement it right away.

A simple algorithm would be to use the one sided bearoff evaluator to
find the moves which bears off in fewest rolls. This costs one lookup in
the onesided bearoff database which would be close to zero.

Another example of provoking behaviour by gnubg is random moves in races
where the match is lost or money game with Jacoby rule where the
opponent hasn't doubled. This will only occur if a human opponent or
buggy bot has rejected a legitimate resign or if gnubg "forgets" to
resign. Do we want gnubg to make the least provoking move in this case
too? My simple algorithm above can be extended to cover such positions
as well by using Joseph one-sided rollout code. However, now the this
features comes with a non-zero prize tag -- do we want to spend a few
seconds of CPU time to find the move  that won't provoke the opponent?

Jørn

Attachment: pgpQsMbshUlAK.pgp
Description: PGP signature


reply via email to

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