Nick Wedd | 31 Mar 12:29 2015

April KGS bot tournament, 13x13

The April KGS bot tournament will be this Sunday, April 5th, starting at 
08:00 UTC and ending by 14:00 UTC.  It will use 19x19 boards, with time 
limits of 9 minutes each plus fast Canadian overtime, and komi of 7.5. 
There are details at

I apologise for the short notice. March seems to have passed unusually 

Please register by emailing me, with the words "KGS Tournament
Registration" in the email title, at maproom <at> .

Nick Wedd      maproom <at>
Computer-go mailing list
Computer-go <at>
Dave Dyer | 29 Mar 16:42 2015

Re: fast + good RNG

>Anyway, it's very easy to make a fast PRNG these days. 

A couple words of caution about hacking PNRG.   

Back in the stone age of computing, some mavens from the triple-i movie
group cooked up a "galaxy simulator" which generated pictures of spiral
galaxies based on a numerical model.  The capability to make pictures was 
rare at the time.

The pictures sucked.  After lots of hunting for flaws in the model,
and tweaking it, the real cause for the poor quality was determined to be
that fortran's "random" numbers weren't very good.  Substitute a better
PRNG, and beautiful pictures emerged.


On a similar note, working with a UCT robot for a blokus clone at, I found that tiny changes in the way PRNG's were used
had measurable effects on the quality of play.  Not necessarily better 
or worse, just different.


So if you're going to hack the PRNG, you should retain the ability
to use a gold standard PRNG instead of your faster-better-cheaper
model, and you should use it once in a while, just to be sure you're
not introducing hidden flaws.

Computer-go mailing list
Computer-go <at>
folkert | 29 Mar 11:50 2015

fast + good RNG


I measured that std::mt19937_64 (the mersenne twister from the standard
c++ libraries) uses about 40% cpu time during playouts.

So I wonder: is there a faster prng while still generating good enough

Folkert van Heusden


Nagios user? Check out CoffeeSaint - the versatile Nagios status
Phone: +31-6-41278122, PGP-key: 1F28D8AE,
Computer-go mailing list
Computer-go <at>
Joshua Shriver | 28 Mar 23:58 2015

Learning from CGOS

What elements did you like about CGOS and what do you wish for?

I've begun writing a new version from scratch that isn't TCL based.
With the aim for future use and also open source and open to public

Computer-go mailing list
Computer-go <at>
folkert | 28 Mar 08:51 2015

monte carlo search; all valid moves?


For a monte carlo search, are only valid moves performed? Or does it
work from beginning to the end of a playout using whatever free position
is available on the board?

Because I read here that people can do 25k playouts per second while my
program can only do ~ 20 per second when doing full validity checks on
all steps.

Folkert van Heusden


Phone: +31-6-41278122, PGP-key: 1F28D8AE,
Computer-go mailing list
Computer-go <at>
Zach Wegner | 27 Mar 22:55 2015

Cogito--another minimal Go engine

With all the talk about Michi (which is very nice btw, Petr!), I
figured now would be a good time to do a little more work on my old
super-minimalist obfuscated Go engine, and finally show it off to the
world. Cogito was mostly written in 2008/2009, I only did some
cleaning up/bug fixing/shrinking.

At current count, using the IOCCC rules, there are only 1891
characters of C source code, or 2277 bytes if counted normally. It
only uses basic UCT with no eye-filling. I might try experimenting
with adding more heuristics, perhaps RAVE, as long as there isn't too
much code required. The code is certainly twisted and unintelligible,
but I might be convinced to write up some explanation of the code
structure and what all the one-character variable names mean...

Cogito has a simple terminal interface, but currently no way to play
through gtp. I once had a shell script that would interface it with
CGOS (where it played a bit in ~2009, with a rating of something like
1300), but it's been lost. I might whip up a little adapter script in
Python if there's interest. For just playing a terminal game, there's
some instructions in the readme.

Without further ado, the repository:
Computer-go mailing list
Computer-go <at>
Urban Hafner | 26 Mar 10:31 2015

How to correctly use GoGui live graphics?

Hey there,

I'd like to use the live graphics feature of GoGui to see what the engine is "thinking" during a game. I played around with it a bit, but I think I'm doing it wrong. I always run into the problem that the output I want to display gets cleared right away by GoGui. I understand why that's happening. For example I try to display the win percentage of the move the engine wants to play, but right after displaying this data I return said move and GoGui removes the data. The same thing happens when I try to display some data about the owner of each point. Again I try to do it right before returning a result to genmove as this seems to be the point at which the engine has the best estimate. Obviously that gets cleared right away, too.

So, is there a way around that? Or is the live graphics feature meant to be used in a different way?

Computer-go mailing list
Computer-go <at>
Petr Baudis | 25 Mar 16:36 2015

[ANN] Michi - 15x15 ~6k KGS in 540 lines of Python code


  So what's the strongest program you can make with minimum effort
and code size while keeping maximum clarity?  Chess programers
were exploring this for long time, e.g. with Sunfish, and that inspired
me to try out something similar in Go over a few evening recently:

Unfortunately, Chess rules are perhaps more complicated for humans,
but much easier to play for computers!  So the code is longer and more
complicated than Sunfish, but hopefully it is still possible to
understand it for a Computer Go newbie over a few hours.  I will welcome
any feedback and/or pull requests.

  Contrary to other minimalistic UCT Go players, I wanted to create
a program that actually plays reasonably.  It can beat many beginners
and on 15x15 fares about even with GNUGo; even on 19x19, it can win
about 20% of its games with GNUGo on a beefier machine.  Based on my
observations, the limiting factor is time - Python is sloooow and
a faster language with the exact same algorithm should be able to speed
this up at least 5x, which should mean at least two ranks level-up.
I attempt to leave the code also as my legacy, not sure if I'll ever
get back to Pachi - these parts of a Computer Go program I consider most
essential.  The biggest code omission wrt. strength is probably lack of
2-liberty semeai reading and more sophisticated self-atari detection.

  P.S.: 6k KGS estimate has been based on playtesting against GNUGo over
40-60 games - winrate is about 50% with 4000 playouts/move.  Best I can
do...  But you can connect the program itself to KGS too:


				Petr Baudis
	If you do not work on an important problem, it's unlikely
	you'll do important work.  -- R. Hamming
Computer-go mailing list
Computer-go <at>
Mark Winands | 15 Mar 18:40 2015

CFP: Computer Games Workshop at IJCAI 2015

Computer Games Workshop at IJCAI 2015




A workshop on computer games is to be held at IJCAI 2015 in Buenos Aires, Argentina. The proceedings will be published with Springer in their Communications in Computer and Information Science series CCIS. The topics of the workshop concern all aspects of Artificial Intelligence for computer games. This includes:

•       Monte-Carlo methods

•       Heuristic search

•       Board games

•       Card games

•       Video games

•       Perfect and imperfect information games

·       Puzzles and single player games

·       Multi-player games

·       Serious games

·       Combinatorial game theory

Important dates


·       Paper Submission Deadline: April 27, 2015

·       Acceptance Notification: May 20, 2015

·       Final Papers: May 30, 2015

Paper Submission Requirements


Papers of 10 to 15 pages in LNCS format are preferred. The file format for submission is PDF. Submitted papers should be sent to cazenave <at>

Program Committee


·       Yngvi Björnsson, Reykjavik University

·       Bruno Bouzy, University Paris-Descartes

·       Tristan Cazenave (chair), University Paris-Dauphine

·       Stefan Edelkamp (chair), University of Bremen

·       Hiroyuki Iida, Japan Advanced Institute of Science and Technology

·       Nicolas Jouandeau, University Paris 8

·       Sylvain Lagrue, University of Artois

·       Marc Lanctot, Google DeepMind

·       Simon Lucas, University of Essex

·       Jean Mehat, University Paris 8

·       Martin Müller, University of Alberta

·       Arpad Rimmel, Supelec

·       Thomas Philip Runarsson, University of Iceland

·       Abdallah Saffidine, University of New South Wales

·       Nathan Sturtevant, University of Denver

·       Fabien Teytaud, University of Littoral Cote d'Opale

·       Mark Winands (chair), Maastricht University

·       Shi-Jim Yen, National Dong Hwa University

For more information:

Computer-go mailing list
Computer-go <at>
holger krekel | 15 Mar 16:18 2015

public valid move generator algorithms?


could anyone point me to a current good public source algorithm
for generating valid moves from a given Go board position?

All else failing, i am going to analyze Gnugo first (board.c mostly)
but wanted to ask for hints here first.  I am mostly interested in
readability of the algorithm, not speed, at this point.  So high-level
language implementations are fine.

many thanks,

Computer-go mailing list
Computer-go <at>
Rémi Coulom | 14 Mar 01:25 2015



We are now preparing for the first round. I'll post photos on Google+ when I have time:


Computer-go mailing list
Computer-go <at>