[Top][All Lists]

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

Re: Not quite {was: Re: [Bug-gnubg] Double Decisions

From: Jim Segrave
Subject: Re: Not quite {was: Re: [Bug-gnubg] Double Decisions
Date: Wed, 22 Aug 2007 00:04:05 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Tue 21 Aug 2007 (13:31 -0400), Roy A. Crabtree wrote:
> Some responses; most of what you said I concur with, but NOT most
> of your conclusions.
> To reiterate: gnubg is a great result.  Keep on keepin' on.


I have a great deal of trouble actually reading your responses, they
often seem to have sections missing or almost appear to be two
different blocks of text interleaved.

As far as I can tell, you have some serious misapprehensions about
gnubg (and most other bg programs as well.

First gnubg uses three external sources of information:

A table of weights, which determine the behaviour of the neural nets
gnubg uses to evaluate the probable outcome of a game (played without
the cube) given a particular position of the chequers. 

A match equity table (MET), which gives the match winning chances for a
player at a given match score. All of the METs provided with gnubg
assume that both players are equally strong. An interested player
could attempt to make a MET for unequal players - I believe Walter
Trice has explored what such a table would be like. I am not aware of
any such tables being available, but if one is, it could be put into a
format such that gnubg could use it.

A bearoff database which gives the probable number of rolls to clear
all a player's pieces off in non-contact positions. As shipped, gnubg
has such a database for all the player's pieces in his
homeboard. Larger tables, allowing the player's pieces to be on more
points are available for download and gnubg can use them. Experiments
indicate that the neural net is so accurate for this type of race that
there is little purpose served in using them.

These are the sole external data sources for gnubg which can cause its
play to be altered.

Gnubg has no provision for updating any of those sources of data - it
can read them, it will never write them.

Gnubg has a small number of neural nets, each optimised for a
particular type of position - racing (non-contact), contact, crashed
(the player's home board is collapsing). It has a smaller neural net
which is generally used to produce a rough and ready estimate of what
the full net will produce. This is used to prune away un-promising
moves to make evaluations faster.

The point of all this is that gnubg's behaviour is set when the above
data sources are attached to the program. Given two machines running
gnubg, as long as both use the same neural net weights, MET and
bearoff database, then both copies will play identically. They will
_always_ play the same way, no matter if they lose 100,000 games in a
row. Gnubg's behaviour is static in that sense. It does not learn, it
does not adapt, it does not get better, it does not get worse.

It does not have some database of neural net responses or whatever you
were trying to suggest in your posting. 

It does not choose moves using a neural net.

It does not make cube decisions using a neural net.

The only thing it does with the neural nets is estimate the
probability of the various outcomes given a particular arrangement of
the chequers. 

The choice of move is done by examining the nn outputs for the
position resulting from each of the possible legal moves, then for
each of the better ones of those, the possible dice rolls and moves
for the opponent, for each roll, it tests the resulting position again
and calls the neural net for a new estimate. Eventually, it chooses
the move giving the highest equity for itself

Similarly, the cube decision is made by examining all the possible
rolls that could occur and the resulting best position for each roll,
eventually leading to an expected value for the winning/gammon/bg
chances before the dice are rolled.

At no time does gnubg have any information about forthcoming rolls,
even when using one of its own built in random number generators.

There is no code in gnubg to analyze the supplied random numbers to
see if there is some possibly useful statistical bias.

There is no code in gnubg to analyse its opponent's play to allow it
to alter its estimate of the win/gammon/bg/lose/lose gammon/lose bg

It is static and, given the same dice rolls it will play the same game

The neural nets can be trained to generate new weights for the various
nets. Training is done using separate software derived from, but not
identical to, gnubg's. Effective training involves rolling out
positions tens and hundreds of thousands of times to get sufficient
information to allow adjusting the weights. Even if gnubg were
adaptive, even the most fanatical player couldn't play enough games to
produce any perceptible change in gnubg's weights, and hence it's
style of play.

In short, gnubg is about as dynamic as your average housebrick.

Jim Segrave           address@hidden

reply via email to

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