CMPUT 657 Class Notes

Extra material from class, usually done on the whiteboard.

Contents:

October 9 Notes
October 7 Notes
October 2 Notes
September 18 Notes
September 16 Notes
September 4 Notes
September 2 Notes

October 9

Canonical Forms Get Large Quickly

CGSuite examples, try them out

{1|-1}
{2|-2}
{1|-1} + {2|-2}
{1|-1} + {2|-2} + {3|-3}
{1|-1} + {2|-2} + {3|-3} + {4|-4}
{1|-1} + {2|-2} + {3|-3} + {4|-4} + {5|-5}
{1|-1} + {2|-2} + {3|-3} + {4|-4} + {5|-5} + {6|-6}
{1|-1} + {2|-2} + {3|-3} + {4|-4} + {5|-5} + {6|-6} + {7|-7}
{1|-1} + {2|-2} + {3|-3} + {4|-4} + {5|-5} + {6|-6} + {7|-7} + {8|-8}
{1|-1} + {2|-2} + {3|-3} + {4|-4} + {5|-5} + {6|-6} + {7|-7} + {8|-8} + {9|-9}

Clobber examples:

game.grid.Clobber("OX").CanonicalForm
game.grid.Clobber("OXOXOX").CanonicalForm
game.grid.Clobber("OXOXOXOXOX").CanonicalForm
game.grid.Clobber("OXOXOXOXOXOXOX").CanonicalForm
game.grid.Clobber("OXOXOXOXOXOXOXOXOX").CanonicalForm
game.grid.Clobber("OXOXOXOXOXOXOXOXOXOXOX").CanonicalForm

Bug Fix

There was a mistake on slide 20 of "comparing games", that we hit at the end of last class: in the game G = {0, ∗,−1|−1, {1|−2}, {2|0}}, everything I wrote about comparing options is true. In particular, −1 and {1|−2} are incomparable. However, the final statement is wrong: Canonical form: G = {0, ∗|−1, {1|−2}}. Why is it wrong? It is because of the other simplification, reversible moves. In this case, Right should never move to {1|−2}, since Left can immediately answer and move to 1, which is greater than G itself (because the Left options from G are "only" 0 and *). So the canonical form of G is {0, * | -1}, without that reversible Right option.

To make the example work as intended, and keep {1|−2} in the canonical form, the left options need to be better, so I replaced them by 2, 2 + * and made a new version of the slides with this fix. The canonical form of G:= {2, 2+*, -1 | -1, {1|-2}, {2|0}} is indeed {2, 2* | -1, {1 | -2} }. This is the kind of thing that is very easy for humans to miss, but CGSuite catches it easily.

October 7

The "Outcome Diamond" and Comparing Games

The outcome diamond is the partial order between game outcomes shown above (Figure from Urban Larsson's paper). If you have to choose a game based on its outcome, then as Left you always choose outcome L over any game with outcome in N, P, R, and you choose any other outcome over R, while outcomes N and P are incomparable.

However, that does not mean that e.g. any game in L is better than any game in another class in terms of direct comparison. For example, consider the games G = 1, and H = 100 | 0. Clearly, G is in L and H is in N, since Right can win H by moving to 0. So if left had to choose a single game, Left should choose G since it is a sure win, while H is not. However, G and H themselves are incomparable. There are many sums where having the option to move to H is more valuable than moving to G. For example, with game K = 0 | -50, the sum G + K is in N, but H + K is in L.

Whiteboard

Thanks Abel!

October 2

MCGS analysis of Domineering game from class

White (students) is horizontal and goes first. This is with the "more-grid-games" branch of MCGS, which includes the rules of domineering.

Students played perfectly according to MCGS - all White to play positions are wins, and all Black to play positions are losses.

Moves (left square for White, top square for Black): 1. A2, 2. E5, 3. E4, 4. E1, 5. C2, 6. B5, 7. A4, 8. C5, 9.C4, 10. F2. Now horizontal has 4 more moves, and vertical only 3, so horizontal wins. Below are the calls to solve all game positions with MCGS.

./MCGS "[domineering] ......|......|......|......|......|...... {W}"
./MCGS "[domineering] ......|##....|......|......|......|...... {B}"
./MCGS "[domineering] ......|##....|......|......|....#.|....#. {W}"
./MCGS "[domineering] ......|##....|......|....##|....#.|....#. {B}"
./MCGS "[domineering] ....#.|##..#.|......|....##|....#.|....#. {W}"
./MCGS "[domineering] ....#.|#####.|......|....##|....#.|....#. {B}"
./MCGS "[domineering] ....#.|#####.|......|....##|.#..#.|.#..#. {W}"
./MCGS "[domineering] ....#.|#####.|......|##..##|.#..#.|.#..#. {B}"
./MCGS "[domineering] ....#.|#####.|......|##..##|.##.#.|.##.#. {W}"
./MCGS "[domineering] ....#.|#####.|......|######|.##.#.|.##.#. {B}"
./MCGS "[domineering] ....#.|######|.....#|######|.##.#.|.##.#. {W}"

Comments on Nim game from class

Let *n denote a nim heap with n stones. We played the game *3 + *4 + *5. A winning move is to move from *3 to *1, leaving the sum *1 + *4 + *5. This is a losing position (2nd player win)

A few more examples of losing positions: *n + *n (second player copies the first player's moves), *1 + *2 + *3.

There is an analysis of this game based on the binary representation of heap sizes, and bitwise XOR. We will talk about it in class soon.

September 18

Represent a 1x10 Q1game in 16 bits

Each cell has 3 states, can encode as numbers empty = 0, black = 1, white = 2
Whole board with n cells can be written as a base 3 number with n digits, e.g. n=10, board representation = 0100002000, corresponds to empty, black, empty, ...
0100002000 = 0*3^9 + 1*3^8 + ...+2*3^3
With 10 base 3 digits, can write all numbers from 0 to the largest: 2222222222 = 3^10 - 1
There are 3^n different base 3 numbers with n digits, each corresponds to a different board.
It takes k = ceil(log_2(3)n) bits to represent such numbers, where log_2(3) is the base 2 logarithm of 3, about 1.58496... k is the smallest number such that 2^k ≥ 3^n.

Bit-wise XOR

XOR rules: 0^0 = 0, 0^1 = 1, 1^0 = 1, 1^1 = 0

8-bit bitwise XOR
a = 01101001
b = 10001110
---------------------
c = 11100111
c = a xor b

Rule: x xor x = 0 for all x (you can check this for single bits)
Example: c xor b = 01101001 = a
Zobrist table for Q1game: code[10][3] = table of random (say 64 bit) numbers
Encoding Empty = E = 0, Black = B = 1, White = W = 2
Example: 1x5 board, initially empty EEEEE
board code = code[0][0] xor code[1][0] xor ...code[4][0]
play move to EEEBE: remove code[3][0], add code[3][1], both using xor

Hash collision

Hash collision: code(board1) = code(board2), but board1 != board2
Chance of hash collision: Two n-bit random codes, chance that they are the same = 2^(-n)
In a search we have m states, m can be large. Chance of no collision in the whole search: No pair of states s1, s2 has a collision. There are choose(m, 2) pairs of states. Probability of no collision: (1-2^-n)^choose(m, 2). We did some numeric examples. What error rate is acceptable?
For proof, we want 0 error. We can verify a probabilistic proof which depends on hashing. The verification should not rely on trusting hash codes.

September 16

See updates: Canvas discussions, Quiz 1 on Canvas, new materials on website
upcoming conference: Advances in Computer Games conference (ACG 2025), October 21-23. online, free registration
Illustration for Principal Variation (PV): Chess analysis with PV by strong chess program Sesse

September 4 Notes

Proof that XOXOXO is a second player win. Thanks Abel for the picture!
Solving 1x10 Clobber, XOXOXOXOXO, in three tree nodes: X can play to XOXOXO.XXO = XOXOXO + XXO. Since XOXOXO is a second player win, no player can profit from playing there. So we can ignore that part and focus on XXO. O to play has only one move, to XO.. From here, X to play can clobber the last O stone and win.
Picture - State space for 2x2 Clobber. Thanks Yuzhang!
We looked at two variants, a "naive" state space, and a smaller one where equivalent states (just differ by rotation) are merged into a single state, e.g. by defining a "normal form". Also, we discussed that we can simplify games with "zero subgames", as we did in simplifying XOXOXO + XXO to XXO.
Example of a large Go puzzle that can be solved by local search and CGT methods. Also, failure of full-board search to scale to large problems.

September 2 Notes

Clobber game from class, and analysis with MCGS and CGSuite. The student team played perfectly, and I had no chance!

Last update: Sep 21, 2025, Martin Müller