On Fri, 2007-09-28 at 18:43 -0400, Don Dailey wrote:
> Somewhere in your program I am sure there is a head-slapping error you
> will find and when you do you will scream out loud! Don't give up.
Yup... A nice little omission of casting.
int nwins, nsims;
...
double winRate = nwins/nsims;
...
write("Picking move {} with win rate of", move, nwins*1.0/nsims);
What kept me from seeing this immediately (AKA bot plays
A1,A2,A3...A9,B1,B2...B9,C1...C9,...) is that there's logic that looks
at two moves with the same winning rate and picks the one with the
higher number of simulations. That can really help in non-AMAF
implementations where the number of sims are low.
It turns out that the code that I copied/pasted to make a quick AMAF bot
used floating point numbers for nwins and nsims... My so-called monte
carlo transposition reuse (MCTR) where they have to be floating point
values.
I kicked off hb-amaf-1k-v2. While it lost its first game online, it's
play was WAY better than it has been. It's rating will certainly settle
much higher.
I hope that was the issue and there are no more biggies like that! This
discussion was very helpful for me to dig up all kinds of small bugs in
other parts of my code. Once I confirm this is the big bug, I'll try
variants with the different handling to see how that affects the rating
(I'd call all past tests of variations worthless given the nature of
this bug)
While this may give an 800 ELO boost to the AMAF bot, I'm disappointed
that it won't help my other versions like that. The other changes dug
up in this long discussion will likely give them some boost though.
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
