I often found similar for Zen with enough memory. I and Yamato's
interpretation follows.
Yamato tunes many parameters with relatively shorter time settings
because a huge number of games are necessary for the tuning. Assuming
the prior bias and the average outcome from the simulations have
>I have seen this exact behavior when first experimenting with long thinking
>times in Pachi. When you stop growing the tree, the algorithm degenerates to
>"delayed" single-level Monte Carlo along the principal variations, with all
>the MC-without-tree weaknesses.
The pathology definitely depe
On Fri, Nov 06, 2015 at 10:48:49AM -0800, Dave Dyer wrote:
>
> Developing a UCT robot for a new game, I have encountered a
> surprising and alarming behavior: the longer think time the
> robot is given, the worse the results. That is, the same robot
> given 5 seconds per move defeats one give 30
>But you are stopping right at the atari, and then pile on playouts that make
>it seem work...
Yes, something like that may be the situation that turns the result.
Suppose the tree stops at a point where there are two moves, a
blunder that leads to a quick end, and another move which leads
to
At 11:24 AM 11/6/2015, Tobias Pfeiffer wrote:
>If you remove the limit on the tree size, does this still occur?
Exactly. That's why I reported the tree size limit as the likely culprit.
It's still hard to imagine how that results in the observed behavior.
_
This is expected. Search for the horizon effect related to computer go
(e.g. in Petr Baudis thesis http://pasky.or.cz/go/prace.pdf)
On Fri, Nov 6, 2015 at 8:48 PM, Gonçalo Mendes Ferreira
wrote:
> That's certainly possible, but assuming the tree is being limited on
> number of nodes, not constan
That's certainly possible, but assuming the tree is being limited on
number of nodes, not constant depth, and the selection of equal quality
candidates to explore is random, how likely is it to happen? The problem
seems to be constant.
On 06/11/2015 19:29, Marc Landgraf wrote:
It is indeed ve
At 10:59 AM 11/6/2015, Gonçalo Mendes Ferreira wrote:
>That doesn't seem very realistic.
This is with a well tested framework that's been used for 20+ games.
Whatever the ultimate resolution, the counter intuitive result that
triggered it stands alone; longer think times give worse results.
I ha
It is indeed very realistic and can be recreated in Go.
The issue is, that you are chopping of the tree at a fixed point and this
may heavily bias the the entire tree, if this point influences the playout.
Like imagine there is one big Atari in the entire game, but it can be
easily answered. If yo
If you remove the limit on the tree size, does this still occur?
Otherwise, I agree with Gonçalo - it seems unlikely. When I implemented
Double Step [1] and had weird results I forgot to switch the perspective
of the bots and even worse some of the move generation was buggy.
Cheers,
Tobi
[1] a t
That doesn't seem very realistic. I'd guess your prior values are
accurate but the simulations are biased or not representative. Or you
miss precision in your transition quality floating points. Or there's a
bug related to being an adversarial problem and you didn't have the
robots swap colors?
Developing a UCT robot for a new game, I have encountered a
surprising and alarming behavior: the longer think time the
robot is given, the worse the results. That is, the same robot
given 5 seconds per move defeats one give 30 seconds, or 180 seconds.
I'm still investigating, but the proximate
12 matches
Mail list logo
