Now it is around 1590 elos on cgos so I guess it is ok.
I have a question about domain dependent knowledge used like "don't fill
eyes".
Obviously it helps a lot in converging the game to an end. My main interest
however is in methods that can
be used for a general game playing program (GGP) . I am reading a very
interesting paper
"Simulation-Based Approach to General Game Playing"
http://www.aaai.org/Papers/AAAI/2008/AAAI08-041.pdf
It uses UCT and other method to select features (like don't fill eyes) to
improve the MC playouts automatically.
One of the conclusions given there is
*"*
*Simulation methods work particularly well in ”converging” games (e.g.
Othello, Amazons, and Breakthrough),*
*where each move advances the game closer towards the end,*
*as this bounds the length of each simulation playout. However,
simulation-based methods may run into problems in*
*games that converge slowly — we have observed this in*
*some chess-like games (e.g. Skirmish played in the GPP*
*competition).*
*"*
I am also getting the same result in my general game playing engine. By far
UCT was successful in "Game of Amazons",
huge branching factor (~3000) but game ends in 80 or so moves, then Reversi
, then Go, then Checkers and least successful in
chess so far (the only game) ! I think the chess UCT can be improved by
giving priority to captures but I haven't tried it so far.
That was guaranted in case of checkers as captures are forced.
Are there attempts to learn features (f.i "don't fill eyes" in Go) that can
improve the monte carlo playouts automatically, like in the GGP
paper I mentioned above ? Also I read improvements such as AMAF and RAVE to
UCT. I did not
go through it in detail but they sound like methods specific to Go , right?
I don't think that
a move explored at ply=20 and found out to be good canbe used to current
moves at current ply
for other games than Go...
Thank you.
P.S : To Aja: sorry for mispeling your name :)
To Joona : I think the heavy playout scheme should first be improved.
With random light
playouts speed may not matter that much compared to
slightly improving the accuracy.
But I suspect it should matter once the heavy playout
scheme is sufficiently accurate.
On Sun, Mar 27, 2011 at 5:56 PM, Joona Kiiski <[email protected]>wrote:
> Thanks for the description. If a simple eye detection such as that
>> works , then it should accelerate the MC playouts very much.
>> I will try it.
>>
>
> Yes it works, I guess every top program does pretty much the same.
>
> However one of my early observations with Go programming has been
> that the speed is not a very big issue in this field (at least in lower
> levels).
>
> From 9x9 CGOS:
>
> iva-0.1 <http://cgos.boardspace.net/9x9/cross/iva-0.1.html> (1687), fixed
> 100k playouts/move
> iva-0.2 <http://cgos.boardspace.net/9x9/cross/iva-0.2-dev1.html> (1795), 4
> threads, optimized time usage, ~1M playouts/move
>
> 10x more processing power only gave around 100 extra elo points.
>
> Of course with heavy playouts and more fine tuned programs things can
> be very different...
>
> _______________________________________________
> Computer-go mailing list
> [email protected]
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
