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: Mark Higgins
Subject: Re: [Bug-gnubg] Neural network symmetry question
Date: Mon, 12 Dec 2011 15:11:45 -0500

I ran my test out to 400k runs and the "symmetric" network starting drifting 
down, with the normal one edging it out in head to head competitions.

But the real evidence against it came from looking at probability estimates 
from a couple benchmark positions: one where white is almost certainly going to 
win, and one where white is almost certainly going to lose. The symmetric case 
did much worse than the normal case in those examples. 

I assume this is what the gnubg benchmark stuff is about btw? Comparing 
probability estimates in a bunch of benchmark board positions against 
rolled-out probabilities? How do you condense the many different cases into a 
single number - ie sum( weight * difference^2 ) - how do you relatively weight 
the different benchmark positions?

Also I thought some more about the basic implications of this symmetry 
constraint and it just seems wrong: the network probabilities are a fn of 
difference in white and black inputs instead of each separately. That a priori 
just doesn't seem flexible enough. 


On Dec 11, 2011, at 5:44 PM, Joseph Heled <address@hidden> wrote:

> My experience tells me that 100,000 trials may not be sufficient.
> 
> With today's computing power  it should be easy to do at least a
> couple of millions.
> 
> -Joseph
> 
> On 12 December 2011 11:22, Mark Higgins <address@hidden> wrote:
>> I tried a little experiment on this: a 10-hidden-node network with a single 
>> probability-of-win output, but two setups. The first doesn't have a "whose 
>> turn is it" input and doesn't add any symmetry constraints. The second has 
>> the extra inputs for the turn and makes the symmetry constraint I described.
>> 
>> I trained them in parallel and benchmarked them against pub eval and against 
>> each other.
>> 
>> The symmetric case performed a little better: it trained more quickly, did 
>> better against pub eval, and was on par or a little better than the other 
>> case when playing head to head.
>> 
>> Details and data here:
>> 
>> http://compgammon.blogspot.com/2011/12/testing-value-of-symmetry-constraint.html
>> 
>> Of course not conclusive with such a simple setup, but kind of suggestive 
>> anyways.
>> 
>> 
>> 
>> 
>> On Dec 10, 2011, at 2:22 PM, Mark Higgins wrote:
>> 
>>> Thx! Makes sense. Though I wonder if adding back in the "whose move is it" 
>>> input and reducing the hidden->output weights by half ends up as a net 
>>> benefit for training. Maybe I'll test it out.
>>> 
>>> 
>>> 
>>> On Dec 10, 2011, at 2:06 PM, Frank Berger <address@hidden> wrote:
>>> 
>>>> Hi Mark,
>>>> 
>>>>> If I take a given board and translate the position into the inputs and 
>>>>> then evaluate the network, it gives me a probability of win. If I then 
>>>>> flip the board's perspective (ie white vs black) and do the same, I get 
>>>>> another probability of win. Those two probabilities should sum to 1, 
>>>>> since one or the other player must win (or equivalently, the probability 
>>>>> of white winning = probability of black losing = 1 - probability of black 
>>>>> winning).
>>>> 
>>>> 
>>>> I assume your assumption is wrong. IIRC in an earlier paper there was an 
>>>> input to indicate who's on. It is much simpler to present the position 
>>>> from the point of the moving player, because the net has to learn less. 
>>>> I'm not that familiar with the gnubg code, but I think they do it in this 
>>>> way, so you can't just turn the perspective.
>>>> 
>>>> ciao
>>>> Frank
>>>> _______________________________________________
>>>> 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]