bug-gnubg
[Top][All Lists]
Advanced

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

Re: [Bug-gnubg] Neural network symmetry question


From: Joseph Heled
Subject: Re: [Bug-gnubg] Neural network symmetry question
Date: Sat, 17 Dec 2011 08:47:48 +1300

It is true that for moves we are interested only in relative
evaluations between moves, but in cube actions we are interested in
relative and value against the drop point.

The GNUbg training data contained both "move" positions and "cube
action" positions.
My idea was (and I am not sure if this was original, probably not) to
add training data incrementally. For moves, this consisted of a pair
or positions - one with the "best" move, the other with the move
chosen by the net. For cube actions it was just the position. And the
values where obtained from the 2ply evaluation by the same net. This
may be one of the main sources of the odd/even ply issue, but it was
not obvious how to overcome this.

With today CPU power, I wonder if GNUbg can play using medium length
roolouts using a very small net. At least this may be able to indicate
the places where gnubg fails to see the long term.

-Joseph

On 17 December 2011 04:48, Ian Shaw <address@hidden> wrote:
> This is nothing to do with what I’m talking about (which is optimising the
> nn for “perfect” play), but it’s an interesting idea to contemplate.
>
>
>
> It could be successful, if the bot can account for the opponent’s error
> rate. Typically, it could take worse positions if believed the opponent
> would misplay them.
>
> However, you need to consider what happens if the opponent is actually
> superior. The bot would think the player was making errors, and adjust
> accordingly, but it would be adjusting in the wrong direction. Take my
> previous example: the bot would take a position it would drop if it assumed
> perfect play, and by taking is in an even worse position because it is being
> outplayed.
>
>
>
> It’s possible that this could be overcome by factoring in some luck analysis
> and variance reduction to realise that it is being outplayed because the
> opponent is too unfeasibly “lucky”, but I’ve not really  thought about this
> angle.
>
>
>
>
>
> n  Ian
>
>
>
> From: Thomas A. Moulton [mailto:address@hidden
> Sent: 16 December 2011 12:00
> To: Ian Shaw
> Cc: Øystein Schønning-Johansen; Mark Higgins; Frank Berger;
> address@hidden
> Subject: Re: [Bug-gnubg] Neural network symmetry question
>
>
>
> If gnubg could estimate the opponents rating based upon error rate then it
> could be more aggressive
> on a redouble since the other player is likely to make errors to modify the
> cube decision.
>
> This may have NOTHING to do with what your're talking about right now... :)
>
> Tom
>
>
> On 12/16/2011 06:43 AM, Ian Shaw wrote:
>
> Øystein Schønning-Johansen wrote:
> Sent: 12 December 2011 20:59
>
>
> So, we don't care about the exactness of the absolute evaluation, we care
> about the relative evaluation between the moves (or resulting positions
> after each move). That is what makes it select good moves!
>
>
>
>
>
> This strategy was originally adopted by Tesauro. I agree that it is fine for
> chequerplay, where you only have to find the best play relative to the
> alternatives.
>
>
>
> However, for cube decisions it is important to know the absolute equity. It
> is known that gnubg is inaccurate in some areas, most notably holding-game
> cube action, where gnubg overestimates the holding player’s chances. I
> wonder if this is due to only training for relative move selection.
>
>
>
> It might be worth devising a training regime that trains for absolute
> equity. This ought to give good chequerplay, too, since if the nn can
> accurately determine the absolute value of each position it will inevitably
> rank candidates correctly, too.
>
>
>
> Ian
>
>
>
>
>
> _______________________________________________
>
> Bug-gnubg mailing list
>
> address@hidden
>
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>
>
>
> _______________________________________________
> Bug-gnubg mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>



reply via email to

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