[Top][All Lists]

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

Re: [Bug-gnubg] Is it time for Gnubg 0.15? Improving the evaluation func

From: Joseph Heled
Subject: Re: [Bug-gnubg] Is it time for Gnubg 0.15? Improving the evaluation function
Date: Wed, 19 Jul 2006 00:27:07 +1200

lots and lots of hard questions.

On 7/18/06, Ian Shaw <address@hidden> wrote:

I think Snowie have adopted this approach - using seven nets. I can't
remember where I saw this information, though.

If we could split the nets, I would try using fuzzy logic to smooth out
the gaps at the edges. A position could be evaluated as being 60% prime,
35% holding, 5% race. The evaluations from those nets would then be
combined proportionally to give an overall equity. Maybe Snowie already
does this.

Well, you first have to find a way to assess the percentages (using
fixed one does not buy you anything in my book. IMBW (i may be wrong).
Second, the current race net can be used only for race positions, as
in has different outputs.

However, it should be pointed out that this would mean evaluating each
position using a number of networks. This would slow the evaluation
function down, not to mention the overhead of defining the position
class and combining the weighted results.

One of the advantages of Gnubg over Snowie is that it is much faster. It
is also just as strong as Snowie even though it uses one network for
about 80% of positions.

My conclusion is that is isn't worth the effort. I would rather
concentrate on improving the one neural net. I've started looking at the
evaluation function CalculateHalfInputs, to try to understand what the
current inputs are, and where we might add some more. (It's a hell of a
way to learn C!) I understand the raw board encoding, it's the
hand-crafted features I'm looking at.

Does anyone have any idea why those particular inputs were chosen, what
they are intended to model, and how effective they are? Some of them are
obvious  well commented, but others at the bottom of the enum are

I spent considerable amount of time on this issue with only limited
success. some of them I inherited from Gary's  0.1 version of gnubg.
Some I added. Some I eliminated when I decided they don't contribute.

The issue of inputs to a neural net is as close to the pit of hell as
you can get. There is no science I know of, just black magic. Nothing
I tried really worked. For example
 - train net only on raw inputs.
 - for each of the extra inputs, correlate it with the net error.
(here is one place where a benchmark comes handy)
 - take the input with highest score, add it and re-train.
 - repeat the steps above

The problem is that maddenly even inputs with low correlation benefit
the evaluation, possibly via interacting with other inputs. I tried
this with multiplying two raw inputs to get a new input as well.

I also see that some of the inputs, A_CONTAIN and I_CONTAIN, also have
the same value squared. I'm curious as to why.

Because both proved beneficial by the method above.

To try to understand it, I set up some positions in gnubg and looking at
the evolution output. However, most of the values seem to be zero. What
is going on? For example, BREAK_CONTACT always seems to be zero, even
when there is contact.

Then something is horribly wrong.

I have the idea of trying to encapsulate the concepts from Robertie's
"Modern Backgammon" into the new inputs. These are connectivity,
flexibility, robustness and non-commitment. Some of these may already be
covered, under another name, in the network inputs, which is one of the
reasons I am trying to understand what is there now. They may also be
implicit in the raw board encoding. For example,
Connectivity: Might be measured as the sum of the distances from each
chequer to the next one in front of it.
Flexibility: Might measure the number of point-making rolls for the
spares and blots.

Maybe I_MOBILITY and I_MOMENT cover these concepts, though.

If new inputs are developed, would it be useful to firstly test them on
the pruning net? As I understand it, the pruning net uses the same
inputs as the main net, but only five hidden nodes. I assume its much
quicker to train.

The pruning nets use only the raw 200 inputs.

On the subject of hidden nodes, how much work has been done on
optimising their number? Is there any mileage here?

Adding more hidden nodes did not positively improve the current net.
this should be that least of your worries. start with a number large
enough which you can afford while training. perhaps investigate
bringing the number down after you have a better net. The computing
power today is at least 4-5 times more than we had 3 years ago, so you
should worry about that. I think there was some improvement in using
processor parallelism inside the net evaluation.

-- Ian

reply via email to

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