[Top][All Lists]

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

Re: [Bug-gnubg] gnubg defends poorly against outer primes

From: Øystein Johansen
Subject: Re: [Bug-gnubg] gnubg defends poorly against outer primes
Date: Wed, 26 Nov 2003 20:25:16 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2.1) Gecko/20021130

Misja Alma wrote:
I have a few questions about the training of gnubg. Perhaps one of you can
help me out?
In reply to my mail about gnubg's poor handling of outer primes, Øystein
wrote that it was extremely hard to train those positions. Why is that?
I have read the interesting article 'the gnubg training program' on the
internet, and I know some about neural nets myself, but I still don't
understand? If the problem is in the evaluating of benchmarks because
gnubg's rollouts are biased, why not let them be rolled out by Snowie? This
seems to handle them pretty well.

Hi again!

I'm sending you a link a mail from Joseph on this issue.

The post is about containment positions, but the same applies to outside prime positions.

Using Snowie to roll out positions have some major drawbacks. First of all the platform it's running on. Then it's not possible to automate the rollout process, since the rollouts must be performed from the GUI. It will be a hell of a work to make a program for doing these automatically from a program, and it will be a lot of work to set up all the positions manually since it will be an enourmous amount of positions. Then: How do we know that Snowie plays this correct. What if we train gnubg to make the same mistakes as Shitie^H^H^H^H^Hnowie? Then again I don't think many of the developers own a copy of Snowie so the availability for doing rollouts with Snowie won't be that high. I also think it will have a tast of shame if we use this approach.

I rather think an expert system trained network can work as a starting point. This will also be _very_ slow process, but I think it will be considerably better than than using Snowie.

My other question is about the fact that gnubg uses three different neural
nets; the crashed net, the race net and the contact net. I can see how gnubg
knows when to use the race net, but how exactly does it know when to use the
crashed net and when the contact net? I could imagine there are some
borderline positions there.

It's a CRASHED position if a player have only 6 or less loose checkers to play, and the remaining checkers are crashed on the acepoint, duecepoint or borne off. From eval.c line 1925 ff.

    if( nBack + nOppBack > 22 ) {

      /* contact position */

      unsigned int const N = 6;
      unsigned int i;
      unsigned int side;

      for(side = 0; side < 2; ++side) {
        unsigned int tot = 0;

        const int* board = anBoard[side];

        for(i = 0;  i < 25; ++i) {
          tot += board[i];

        if( tot <= N ) {
          return CLASS_CRASHED;
        } else {
          if( board[0] > 1 ) {
            if( (tot - board[0]) <= N ) {
              return CLASS_CRASHED;
            } else {
if( board[1] > 1 && (1 + tot - (board[0] + board[1])) <= N ) {
                return CLASS_CRASHED;
          } else {
            if( ((int)tot - (board[1] - 1)) <= (int)N ) {
              return CLASS_CRASHED;

      return CLASS_CONTACT;
    else {
      /* Check if it's race or bearoff */


reply via email to

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