bug-gnubg
[Top][All Lists]
Advanced

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

[Bug-gnubg] Resignation bug reported at bgonline.org


From: Philippe Michel
Subject: [Bug-gnubg] Resignation bug reported at bgonline.org
Date: Wed, 15 Apr 2015 23:05:37 +0200 (CEST)
User-agent: Alpine 2.20 (BSF 67 2015-01-07)

A bug where gnubg offers to resign a single game from :

    GNU Backgammon  Position ID: OwAAwL13gAAAAA
                    Match ID   : AQEAABADgAAE
    +-1--2--3--4--5--6-------7--8--9-10-11-12-+  O: GNUbg (Cube: 2)
    | O  O  O  O       |   |                O |  49 points
    | O  O  O  O       |   |                  |  On roll
    | O  O  O  O       |   |                  |
    |    O  O          |   |                  |
    |                  |   |                  |
    |                  |BAR|                  |^
 XX |                  |   |                  |
 XX |                  |   |                  |
 XX |    X             |   |                  |
 XX | X  X             |   |                  |
 XX | X  X             |   |                  |  16 points
    +24-23-22-21-20-19------18-17-16-15-14-13-+  X: You
                    Pip counts : O 47, X 8

was reported at bgoline.org.


The problem is a combination of the neural net underestimating gammons lost by O :

Position ID:    OwAAwL13gAAAAA
Match ID:       AQEAABADgAAE

Evaluator:      Race

        Win     W(g)    W(bg)   L(g)    L(bg)   Equity    Cubeful
static: 0.000000 0.000000 0.000000 0.000050 0.000000  -1.000050  -1.000050
 1 ply: 0.000000 0.000000 0.000000 0.001895 0.000000  -1.001895  -1.001895
 2 ply: 0.000000 0.000000 0.000000 0.001417 0.000000  -1.001418  -1.001418

and the following code in the SanityCheck() function :

        float noise = 1 / 10000.0f;

        for (i = OUTPUT_WINGAMMON; i < NUM_OUTPUTS; ++i) {
            if (unlikely(arOutput[i] < noise)) {
                arOutput[i] = 0.0f;
            }
        }

I don't know the rationale for it. It seems it is from quite early in gnubg development, maybe it predates the other checks that are in this function. The latter seem to be enough to handle the certain outcomes in non-contact positions.

Is it really useful to keep these truncations for contact positions ?




reply via email to

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