# [Computer-go] longest 3x3 game

John Tromp john.tromp at gmail.com
Sun Feb 21 10:55:05 PST 2016

```dear Darren, Ingo,

> Again by random sampling?

Yes, nothing fancy.

> Are there certain moves(*) that bring games to an end earlier, or
> certain moves(*) that make games go on longer? Would weighting them
> appropriately in your random playouts help?

You could try to weigh moves by how likely they lead to revisiting previous
positions. I think that's the only thing that makes moves worse.

> very interesting. Is it allowed for players
> to pass in between? Do these passes count like
> normal moves?

Yes, passes are implied whenever two consecutively played stones
are of the same color.

> > Found a 582 move 3x3 game...
> Can you give us sgf?

I took the effort of trying to format the 582 game in a more insightful way.
I ended up with lines of positions that mostly add stones, only starting
a new line when a capture of more than 1 stone left at most 4 stones:
The result is attached. I think there is clearly
room for improvement, i.e. make this game much longer.

> My intuition says that there should be a constant
> delta > 0 such that for all board sizes m x n (with
> m > 1, n > 1) there exist games of length
> at least (1 + delta)^(m*n).

This is true, and a delta > 2 follows from a Theorem in an
upcoming paper by Matthieu Walraet and myself.

> And also for m x 1 boards (so, only one "long" streak)
> there should exist games with length above
> (1 + delta)^m (they might be constructed by doing some
> pseudo-counting, starting at one end of the board).

We already have a lower bound of 2^{n+1}-4
as Theorem 9 in our combinatorics paper.

> Might neural nets help to find (very) long games
> for given board size?

Neural nets are not the best way to deal with avoiding superko:-(

regards,
-John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attach.582
Type: application/octet-stream
Size: 7264 bytes
Desc: not available
URL: <http://computer-go.org/pipermail/computer-go/attachments/20160221/89bfbec8/attachment.obj>
```