[Top][All Lists]

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

Re: [Bug-gnubg] Analysis changing the game record and producing garbage

From: Neil Robins
Subject: Re: [Bug-gnubg] Analysis changing the game record and producing garbage
Date: Tue, 6 Oct 2009 10:52:45 +0100

I don't feel these issues are related. I think I have seen this using CMARK with earlier builds but was never that bothered by it because a quick reanalysis put the correct move back in red. My problem, I am guessing, is related to autosave kicking in, and GNU somehow losing track of what the actual move made in the match was. Reanalysing the match from the original mat file does not necessarily reproduce the error.

----- Original Message ----- From: "Michael Petch" <address@hidden>
To: "Neil Robins" <address@hidden>; <address@hidden>
Sent: Tuesday, October 06, 2009 10:21 AM
Subject: Re: [Bug-gnubg] Analysis changing the game record and producing garbage

This may seem like an odd question. But even hthough you did 4-ply did you
happen to do any rollouts of individual moves? I ask this because I reported
almost an identical bug doing rollouts with cmark. It sounds like the same
issue but maybe it occurs more commonly than we realize.

My original report with cmark/rollouts was as below (I bring it up because
it seems it may be related):

Howdy Christian,

I received this problem report below from a friend I recently got to try the CMARK feature out. I decided to try reproducing it, and I can find something
similar. Take  a match that is analyzed. Find a very bad error. Go to that
error and select the first 2 moves in the analysis pane PLUS the move that
the player made (the one in red) and click on CMARK. Rollout the moves with
Analyze/Rollout/Match (Use a small rollout trial size to make it quicker).
When finished go back to the move in the move pane. In most cases the
Rollouts move to the top of the list but the move marked as red (The users
actual move) is now on the wrong move! It seems like this is a small bug. It
appears after the move list has the rollouts added the red mark remains in
its original position and Gnubg now considers that the players actual move.
The red highlight should have moved to the rollout entry. It is suggested
this may affect the computed error rate as well.


On 06/10/09 2:40 AM, "Neil Robins" <address@hidden> wrote:

I have analysed several matches at 4-ply using the 20091002 Windows build. I
am finding the move made in the game record often being changed from that
actually played in the match to what GNU thought best - which obviosly then
renders the rest of the game meaningless garbage full of illegal moves.


 GNU Backgammon  Position ID: sHPkASjg6+ABJA
                 Match ID   : MAH6ACAACAAA
 +12-11-10--9--8--7-------6--5--4--3--2--1-+     O: Opp
 | X           O  O |   | O           X  X |     2 points
 | X           O    |   | O                |     Rolled 46
 | X           O    |   | O                |
 | X                |   | O                |
 |                  |   | O                |
^|                  |BAR|                  |     7 point match (Cube: 1)
 |                  |   |                  |
 | O                |   |                  |
 | O           X    |   | X                |
 | O           X    |   | X  X             |
 | O  X        X    |   | X  X     O     O |     1 point
 +13-14-15-16-17-18------19-20-21-22-23-24-+     X: You

 1. Cubeful 4-ply    24/18 22/18                  Eq.:  -0.209
       0.467 0.094 0.002 - 0.533 0.127 0.004
        4-ply cubeful prune
2. Cubeful 4-ply 8/2* 6/2 Eq.: -0.327 ( -0.118)
       0.433 0.146 0.007 - 0.567 0.165 0.008
        4-ply cubeful prune
My opponent moved 8/2* 6/2 which is correctly highlighted in red. The problem is that GNU puts its preferred 24/18 22/18 into the game record in place of
8/2* 6/2 - thus rendering all further analysis of that game meaningless.
This nonsense seems to have affected almost all the games I have analysed.

Bug-gnubg mailing list

reply via email to

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