RE: [Bug-gnubg] Resign bug

[Ric]

I don't doubt that there are legitimate concerns from the programming side
on this issue. In fact, I'll even argue that the current approach is fine IF
the user is notified in some obvious way about what is going on. Even a
popup box announcing "Gnu wins a single game" (or whatever) and thus ending
the game would be a useful approach. My basic point is that the user's
perception of events is sometimes different from the programmer's perception
and the programmer needs to take that into account. (All said with the
understanding that gnubg is a work in progress, of course.) 

Let me note that I'm not a programmer and I'm not a mathematician. I'm a
writer, and my comments come from the perspective of someone who has to
always consider his audience and their perceptions. I feel sufficiently
invested in gnubg becoming a complete success to offer comments when I think
I have a contribution to make. I may be wrong, and I don't mind being shown
where I'm wrong, but I don't much care to be insulted for having made the
offer. 

Ric



-----Original Message-----
From: Joern Thyssen [mailto:address@hidden 
Sent: Monday, August 18, 2003 9:17 AM
To: Ric
Cc: 
Subject: Re: [Bug-gnubg] Resign bug


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