Why are m and n different? Isn't every playout used both to update the UCT
win rate and the RAVE values for the same nodes? Won't the number of UCT
simulations and the number of RAVE simulations be the same?
Each playout is used both to update the UCT win rate and the RAVE
values for the
David Silver wrote:
I think it is time to share this idea with the world :-)
Great. Thanks for sharing.
Rémi
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
Thank you very much, Silver. Interesting report!
-Hideki
David Silver: [EMAIL PROTECTED]:
Hi all,
On 7-Feb-08, at 1:30 AM, [EMAIL PROTECTED] wrote:
Note as well that the current implementation of MoGo (not the one at
the time of the ICML paper) use a different tradeoff between UCT and
Rave
Le vendredi 8 février 2008, terry mcintyre a écrit :
Probably true, but I am already running into RAM
limits with big_Mogo18 - had to halve the number of
instances of the autotest program, and am installing
RAM in the next few days to alleviate this problem.
There is also the time-per-game,
For people requesting mogoRelease3 without the bug for long computation
times due to a float instead of a double:
http://www.lri.fr/~teytaud/mogo (32 bits version, with double instead of
float)
http://www.lri.fr/~teytaud/mogo64 (64 bits version, double also)
Olivier Teytaud wrote:
For people requesting mogoRelease3 without the bug for long computation
times due to a float instead of a double:
http://www.lri.fr/~teytaud/mogo (32 bits version, with double instead of
float)
http://www.lri.fr/~teytaud/mogo64 (64 bits version, double