40% sounds pretty high. Are you sure its not an artefact of your profiling
implementation?
I prefer not to instrument, but to sample stack traces. You can do this using
gdb by pressing ctrl-c, then type bt. Do this 10 times, and look for the parts
of the stack that occur often.
You can name name a specific opponent, and then your bot will play against it.
Automatch works, but tends to result in lots of people being forced to play
your bot, and then leaving the game, after the bot took ages to play in some
ridiculous location, which is kind of embarrassing :-P
Automatch is automatch: the other person doesnt choose to play rhe bot. ___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
By the way, for mcts you dont need time controls. Each move takes the same
amount of time, since you just do n playouts, and choose n as you like.
I think my playouts took 2s, which was enoufht for 4 playouts i suppose,
but it was in novemebr, dont remember clearly... It was obvious that
20 playouts per second is pretty slow. Are you sure youre not just looping
around endlessly for 1 moves or something?
Playing in a dead area is legal, as is filling your own eyes etc. Only suicide,
and ko is illegal. Even superko is a pretty cheap check.
Oh wait, superko check is not that cheap, but it is so rare, you can probably
ignore it in playouts, and jist check befote submitting a move to the server.
If its superko, then jist pass pethaps. ___
Computer-go mailing list
Computer-go@computer-go.org
Cython works well too. Sage uses cython.
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
Oh wow, 640 lines? And gets 6k? Thats impressive! ___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
The important thing is that the games don't have to be played perfectly: They
just need to be significantly better than your current model, so you can tweak
the model to learn from them.
Thats an important incite. I hadnt thought of that.
Maybe could combine with some concept of forgetting,
- Petr's masters paper is good
- i heard on random kgo chat that: uct + RAVE + 3x3 patterns = gets you a 1dan
player
Unfortunately, uct + fast playouts wont get you much further than 25-20 kyo, as
far as i can tell, in my own experience.
(by the way, i was getting 84000 playouts a second on an
Thanks! That's a great data point as it should be easy to run my own bot on
exactly the same hardware
Hmmm, you know what. I bet the playouts i just mentioned were 11x11 playouts...
19x19 should be quite a lot slower...
___
Computer-go mailing
Starting and stopping containers is so fast that I can afford to only start
bots immediately after its opponent plays, request a single move, and
terminate it.
Thats interesting. And impressive.
___
Computer-go mailing list
My bot loses quite capably on 13x13. But it loses even more on 19x19 :-D
Original message
From: Andreas Persson andr...@apgames.se
Date:08/01/2015 5:16 PM (GMT+08:00)
To: computer-go@computer-go.org
Subject: [Computer-go] Testing on different board sizes
Hi,
I am
as I want to by graphic card for CNN: do I need double precision
performance?
Personally, i was thinking of experimenting with ints, bytes, and shorts, even
less precise than singles :-)___
Computer-go mailing list
Computer-go@computer-go.org
Whilst its technically true that you can use an nn with one hidden layer to
learn the same function as a deeper net, you might need a combinatorally large
number of nodes :-)
scaling learning algorithms towards ai, by bengio and lecunn, 2007, makes a
convincing case along these lines.
Aja wrote:
We haven't measured that but I think move history is an important feature
since Go is very much about answering the opponent's last move locally
(that's also why in Go we have the term tenuki for not answering the last
move).
I guess you could get some measure of the importance
16 matches
Mail list logo
