[Computer-go] Seldom, but not alarming

Hi Dave, > 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. Can you tell us the rules of the game? Maybe they help to explain the phenomenon. (Once, Cameron Prowne had strange MC

Re: [Computer-go] Komi 6.5/7.5

2015-11-06 9:41 GMT+00:00 Robert Jasiek : > On 06.11.2015 10:35, Aja Huang wrote: > >> another very strong Chinese pro Shi Yue >> (No.3 at Go ratings >> http://www.goratings.org/, current No.2 in China) said he likes to take >> White

[Computer-go] alarming UCT behavior

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

Re: [Computer-go] alarming UCT behavior

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

Re: [Computer-go] alarming UCT behavior

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

Re: [Computer-go] alarming UCT behavior

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

Re: [Computer-go] alarming UCT behavior

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

Re: [Computer-go] alarming UCT behavior

>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

Re: [Computer-go] alarming UCT 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

Re: [Computer-go] Komi 6.5/7.5

On 06.11.2015 10:47, Aja Huang wrote: area scoring, in which case the score is almost always odd. Black wins: odd score White wins: even score -- robert jasiek ___ Computer-go mailing list Computer-go@computer-go.org

Re: [Computer-go] Komi 6.5/7.5

On 06.11.2015 10:47, Aja Huang wrote: area scoring, in which case the score is almost always odd. Black wins: odd score White wins: even score Aja means pre-komi. It's always odd (except special seki). Jonas ___ Computer-go mailing list

Re: [Computer-go] alarming UCT behavior

>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