These are chat archives for ujh/iomrascalai

13th
Apr 2015
Urban Hafner
@ujh
Apr 13 2015 08:04
I just merged it and I’m running it as 0.2.0-rc2 in CGOS.
iopq
@iopq
Apr 13 2015 08:40
It's actually really hard to get good data, so I'm running 200 simulations or so with each color
to see if it makes a difference
Urban Hafner
@ujh
Apr 13 2015 08:51
Yes, it is. At least on CGOS. Maybe it would be better to go back to running 100 games against GnuGo?
iopq
@iopq
Apr 13 2015 09:07
both? :)
Urban Hafner
@ujh
Apr 13 2015 09:09
In theory, yes. But not today. My internet connection is so crappy that it’s hard to tell if we just loose the games on time or because the bot is so bad. I’ll run 100 games against GnuGo on 9x9 instead.
iopq
@iopq
Apr 13 2015 09:29
weird, it just lost a won game, I need to investigate
pffft it ran out of legal moves
Urban Hafner
@ujh
Apr 13 2015 09:36
So this is a bug then? Does it even make sense to contine running my benchmark against GnuGo?
iopq
@iopq
Apr 13 2015 09:42
this bug exists in the current implementation as well
when we run out of legal moves we'll play in a seki because that's the only move that's not inside an eye and a legal move and we have a non-zero percent chance of winning
that said, it needs to be tuned, I think it makes moves that are too random because of playing out each move 10 times (it plays on the second line and stuff)
iopq
@iopq
Apr 13 2015 09:54
I'll fix the seki issue:
I'll just do what we do normally, but pass/resign only when winrate below 1%
that makes us pass in a seki
instead of trying to make the last legal move
Urban Hafner
@ujh
Apr 13 2015 09:56
Cool. :+1: Now that we run enough playouts doing stuff like this is actually possible.
iopq
@iopq
Apr 13 2015 09:58
it's actually not slower at all because we already check in the resign code if we actually have seki stones on the board, in which case we PASS
I just moved the bound to 1% because by the time our engine sees we have 1% to win we have actually 0% to win
but some random playouts the enemy doesn't capture our atari stones
Urban Hafner
@ujh
Apr 13 2015 09:59
No, I meant compared to a few months ago where be did around 10 playouts a second. :)
iopq
@iopq
Apr 13 2015 09:59
lol
so that's that bug, I put it in its own pull request, I'll tweak the parameters and re-run the simulations
Urban Hafner
@ujh
Apr 13 2015 10:03
Great! I’ll merge it then and run some benchmarks, too. :)
iopq
@iopq
Apr 13 2015 11:28
Interesting results here, on higher time limits the new policy is doing very well
Urban Hafner
@ujh
Apr 13 2015 11:30
I’m currently running 100 games with 5 minutes sudden death on 9x9 against GnuGo level 0. So far it seems to win about 50% of the games.
Unfortunately I don’t have any results to compare this to.
But that’s OK. And from now on it’s actually useful to play against GnuGo as we don’t loose (or win) all games.
Urban Hafner
@ujh
Apr 13 2015 11:38
It would be nice however to “see” more of what the engine is “thinking”, e.g. an overlay of which color owned each intersection over all playouts played for the current gen_move.