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

[Joseph Heled]

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
> undocumented.

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