Castling: A counter-intuitive result

[Daniel Shawul]

Unfortunately most captures in chess are useless. I tried giving more weight to captures but soon realized it was a bad idea. Filtering moves with SEE slows the search down way too much, and even if you do that the result may not improve much since chess is full of tactics, like defending attacks, moving away from forks etc.. But for checkers,i.e with a forced capture, you can get an awesome monte-carlo player. That is the only tactics there and is handled naturally in MC simulations without much effort.

[Daniel Shawul]

Your results are pretty much useless because chess is affected by a lot of tactics, and you can't measure accurately even piece values let alone some positional effects like castling. Here is a UCT search where white is one piece (knight) down, but it still manages to score about 49%. I even use a lot of heuristic to bias move selection, and terminate the playout at some ply and use normal evaluation to decide which side wins, and also a shallow UCT search on the top (upto 3 plies). So for your case that does none of these and goes to the end of the game without using eval(), I won't be surprized if white, which started a piece down, showed a >50% score. So forget about measuring castling effects.

Code: Select all

variant normal
setup (PNBRQ................Kpnbrq................k) 8x8+0_ rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - 0 1
setboard rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKB1R w KQkq - 0 1
montecarlo 1
d

            a b c d e f g h
            * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * *
          8 r n b q k b n r * * * * * * * * * * * * * * * * 8
          7 p p p p p p p p * * * * * * * * * * * * * * * * 7
          6 . . . . . . . . * * * * * * * * * * * * * * * * 6
          5 . . . . . . . . * * * * * * * * * * * * * * * * 5
          4 . . . . . . . . * * * * * * * * * * * * * * * * 4
          3 . . . . . . . . * * * * * * * * * * * * * * * * 3
          2 P P P P P P P P * * * * * * * * * * * * * * * * 2
          1 R N B Q K B . R * * * * * * * * * * * * * * * * 1
            * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * *
            * * * * * * * * * * * * * * * * * * * * * * * *
            a b c d e f g h

                [Material: 5246 5568 ]
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKB1R w KQkq - 0 1

go
[search_time = 5557ms, max_time = 29250ms , moves_left 10, max_nodes 0]
Time : 5586ms Tree : nodes 17618 depth 3/260 pps 5728 visits 32000
h2h3    0.49     910     1853
h2h4    0.49     638     1316
g2g3    0.48     611     1263
g2g4    0.48     425      893
f2f3    0.49     738     1512
f2f4    0.48     617     1274
e2e3    0.50    1494     3002
e2e4    0.48     553     1147
d2d3    0.48     578     1197
d2d4    0.48     571     1183
c2c3    0.49     992     2015
c2c4    0.50    1303     2627
b2b3    0.48     538     1118
b2b4    0.48     590     1219
a2a3    0.49    1180     2385
a2a4    0.49     975     1980
b1c3    0.49    1027     2082
b1a3    0.48     550     1140
h1g1    0.50    1390     2794
Best move : e2e3  from 19 out of 19 moves [100.00%]
move e2e3
setup rnbqkbnr/pppppppp/8/8/8/4P3/PPPP1PPP/RNBQKB1R b KQkq - 0 1
undo
st 120
go
[search_time = 120000ms, max_time = 120000ms , moves_left 10, max_nodes 0]
Time : 120025ms Tree : nodes 381730 depth 5/260 pps 5547 visits 665800
e2e3    0.49   10205    20890
e2e4    0.49   16952    34527
h2h3    0.49   25314    51396
h2h4    0.49   21216    43132
g2g3    0.49   23127    46986
g2g4    0.49   13762    28083
f2f3    0.49   10451    21389
f2f4    0.49   17831    36302
d2d3    0.49   15067    30720
d2d4    0.49   13760    28081
c2c3    0.49   15152    30893
c2c4    0.49   20287    41256
b2b3    0.49   18610    37874
b2b4    0.49   13924    28410
a2a3    0.49   11392    23293
a2a4    0.49   18008    36658
b1c3    0.49   23771    48284
b1a3    0.49   14047    28660
h1g1    0.49   24109    48966
Best move : h2h3  from 19 out of 19 moves [100.00%]
move h2h3
setup rnbqkbnr/pppppppp/8/8/8/7P/PPPPPPP1/RNBQKB1R b KQkq - 0 1

[bob]

Castling: A counter-intuitive result

Player Zero will play a randomly selected castling move if one is available; otherwise, it will play a randomly selected move.

Player One will play a randomly selected move.

What happens in a ten million game match between these players? With alternating colors and from the viewpoint of Player Zero, the win/lose/draw/total counts are:

Code: Select all

W/L/D/T: [762,458/782,299/8,455,243/10,000,000]

Although the effect is slight, why does castling decrease winning chances?

It commits you to one corner. There is an old praxis that says "castle if you want to, or if you must, but NOT just because you can..."

[Uri Blass]

Unfortunately most captures in chess are useless. I tried giving more weight to captures but soon realized it was a bad idea. Filtering moves with SEE slows the search down way too much, and even if you do that the result may not improve much since chess is full of tactics, like defending attacks, moving away from forks etc.. But for checkers,i.e with a forced capture, you can get an awesome monte-carlo player. That is the only tactics there and is handled naturally in MC simulations without much effort.

Most captures in chess against the random player are not useless because even if the capture is a bad capture the opponent will probably not take back.

We do not discuss here about the quality of moves in chess but about result against the random mover.

Even moves that are worse than the random move may improve the
result against the random mover.

[Daniel Shawul]

You talk as if only one of them is a random player, but both are random players and the only difference is the first one prefers castling when it is available. Clearly the MC result is stomped with noise so whatever conclusion you make out of it about the advantage/disadvantage of castling is meaningless. Try with one side a queen/rook down, and you will see the score will not fall down below 48%. So do you seriously expect to figure out the value of castling when you can't do for a missing piece? Like I said the MC players should resolve tactics first and start playing sensible moves (using like SEE, forks, evading danger etc), otherwise what you get out of it is meaning less. Original advantage (like a queen down) will not persist that much down to the endgame and it will probably give it up quickly so it is all random with too much noise.

[sje]

Player Zero will play a randomly selected non-drawing move if one is available; otherwise, it will play a randomly selected move (which will draw the game).

Player One will play a randomly selected move.

What happens in a ten thousand game match between these players? With alternating colors and from the viewpoint of Player Zero, the win/lose/draw/total counts are:

Code: Select all

W/L/D/T: [817/786/8,397/10,000]

These games take a long time to play.

With a one million game match:

Code: Select all

W/L/D/T: [81,644/78,631/839,725/1,000,000]

[syzygy]

Player Zero will play a randomly selected non-drawing move if one is available; otherwise, it will play a randomly selected move (which will draw the game).

Player One will play a randomly selected move.

What happens in a ten thousand game match between these players? With alternating colors and from the viewpoint of Player Zero, the win/lose/draw/total counts are:

Code: Select all

W/L/D/T: [817/786/8,397/10,000]

These games take a long time to play.

With a one million game match:

Code: Select all

W/L/D/T: [81,644/78,631/839,725/1,000,000]

Those 2 results seem to be too close (although it could just be luck). Is your random generator good enough?

[sje]

Those 2 results seem to be too close (although it could just be luck). Is your random generator good enough?

It's random() from the latest Debian C library, seeded at program start with the microsecond resolution epoch.

That's good enough.

[sje]

Player Zero will play a randomly selected non-drawing move if one is available; otherwise, it will play a randomly selected move (which will draw the game).

Player One will play a randomly selected move.

What happens in a ten thousand game match between these players? With alternating colors and from the viewpoint of Player Zero, the win/lose/draw/total counts are:

Code: Select all

W/L/D/T: [817/786/8,397/10,000]

These games take a long time to play.

With a one million game match:

Code: Select all

W/L/D/T: [81,644/78,631/839,725/1,000,000]

With a second one million game match:

Code: Select all

W/L/D/T: [82,005/78,255/839,740/1,000,000]

[Don]

The reason why monte-carlo simulation does not work well in chess is because captures are optional. So step (2) does not work well, since the capture could a loosing one. SEE does not help much either. But for games like checkers you can get a very strong engine even without building a UCT tree, i.e. random palyout right from the root. Biasing selection of other good moves can help but may not be worth it since it slows down rate of random play outs.

I once created a mini-checkers with 6x6 boards and found that randomized playouts was a very powerful evaluation function. I cannot recall the details of exactly what I implemented but the result was a big surprise to me. It makes me wonder how well a MCTS checkers program would play. At first blush one might ask, "why bother?" Checkers programs are so strong now that almost all games between strong players are draws. However, a new frontier for games like this shifts to gamesmanship - how to play provactively to maximize the chances that the opponent will err. MCTS (Monte Carlo Tree Search) will be much more sensitive to moves which increase your winning chances - for example laying traps that your opponent may possibly fall into.