Hmm, sounds like I should experiment some more. Thanks!
Erik
On Thu, Feb 7, 2008 at 1:11 AM, Hideki Kato [EMAIL PROTECTED] wrote:
Hi Erik,
My program is very based on MoGo's report and the paper. Yes, I
used FPU of 1.15.
-Hideki
Erik van der Werf: [EMAIL PROTECTED]:
Hi Hideki,
I also implemented RAVE in Mango. There was a few points of improvements
(around 60 Elo points with gnugo as reference), but as much as in the
paper of Gelly and Silver :( (around 250 Elo points if I remember well)
It might be that the effect of RAVE depends a lot on the simulation
strategy.
I also implemented RAVE in Mango. There was a few points of improvements
(around 60 Elo points with gnugo as reference), but as much as in the paper of
Gelly and Silver :( (around 250 Elo points if I remember well)
It might be that the effect of RAVE depends a lot on the simulation strategy.
Hi Guillaume,
I think we talked about this before, but others may be interested as
well. In my opinion the ICML paper on Rave has several weaknesses.
It's been a while since I read the paper, but here are some I
remember:
(1) They compared Rave to plain UCT. If they would have compared it to
a
Hi Erik,
(1) They compared Rave to plain UCT. If they would have compared it to
a more sophisticated implementation (like the best Mogo before Rave)
they probably could not have shown a spectacular improvement.
The best Mogo before Rave was very close to plain UCT with the
sequence-like
Hi Sylvain,
Thanks for your reply! How do you like your new job? Do you miss CompGo? ;-)
On Wed, Feb 6, 2008 at 2:20 PM, Sylvain Gelly [EMAIL PROTECTED] wrote:
(1) They compared Rave to plain UCT. If they would have compared it to
a more sophisticated implementation (like the best Mogo
I found some data. GGMC Go v2r6, against GNU Go 3.7.10 level 10, 9x9,
komi 7.5, 3000 playouts/move, 2000 games match:
Without RAVE: winning rate was 23.1 +- 0.9% (-209 +- 9 ELO)
With RAVE: winning rate was 65.3 +- 1.1% (+110 +- 8 ELO)
Though this includes some other improvements, most
On Feb 6, 2008 11:39 AM, Gian-Carlo Pascutto [EMAIL PROTECTED] wrote:
Hideki Kato wrote:
4) Before back-propagating the value of each playout, I setup a color
table for all intersections of the board for speed-up, in fact
(initialized with EMPTY). That is, fill the board (table[move] =
Hideki Kato wrote:
4) Before back-propagating the value of each playout, I setup a color
table for all intersections of the board for speed-up, in fact
(initialized with EMPTY). That is, fill the board (table[move] =
color) by tracing the moves and the colors returned by the playout
forward
Gian-Carlo Pascutto: [EMAIL PROTECTED]:
Hideki Kato wrote:
4) Before back-propagating the value of each playout, I setup a color
table for all intersections of the board for speed-up, in fact
(initialized with EMPTY). That is, fill the board (table[move] =
color) by tracing the moves and
Hi Hideki,
Your results look similar to those of Mogo as reported in their icml
paper. When you ran this experiment, did you use anything like FPU or
progressive widening, or did you use Levente's original design which
always selects unvisited moves first?
Regards,
Erik
On Wed, Feb 6, 2008 at
Hi Erik,
In the ICML version of UCT without RAVE, you did not use your First
Play Urgency, right?
I think that using FPU has an effect similar to what others reported
with their progressive widening. From what I've seen it looks like
plain UCT, without FPU or progressive widening, has more
Hi Erik,
My program is very based on MoGo's report and the paper. Yes, I
used FPU of 1.15.
-Hideki
Erik van der Werf: [EMAIL PROTECTED]:
Hi Hideki,
Your results look similar to those of Mogo as reported in their icml
paper. When you ran this experiment, did you use anything like FPU or
13 matches
Mail list logo
