Data augmentation/board flipping

[Akababa]

Continued from https://github.com/glinscott/leela-chess/issues/20#issuecomment-357733977 to avoid derailing that thread.

Shouldn't the data augmentation and board flipping be mutually exclusive? In the current code we already flip the board to get side-to-move on the bottom, so a data augmentation would amount to flipping the color bit, making it pure noise.

[gcp]

If there are no castling rights, you can get some data augmentation with a vertical flip.

[Akababa]

You can also flip horizontally to get 4x augmentation without castling rights, or 2x augmentation with.

[gcp]

I think we mean the same and just use a different definition of horizontal/vertical flip.

Without pawns you can do the flip in the "other" direction, as well as diagonal, but that seems too rare to be worth bothering.

[Akababa]

Yup, basically I think the color plane is extraneous and should be removed to eliminate any worries about white bias.

[glinscott]

Yup, if castling rights are equal for black and white, we can flip the board. That should be a pretty significant win on the number of positions actually.

[brianprichardson]

In addition to the color plane, the final extra padding (120th) layer could also be eliminated.

Also, with the NN then learning just from white to move's point of view (flipping everything, including castling rights, ep, reps), would there be any need to deal with weight symmetry?

This is still not adding any chess knowledge IMO relative to the AGZ approach, and surely given the LCZ hardware handicap, it does seem like a reasonable option.

Thanks.

[ddugovic]

Just how bad is a simplifying assumption that if the king and rook(s) are on their original squares, castling is legal? I've never seen a master game where the king returned to its original square and later had an "opportunity" to castle and the illegal castling move was a good move.

[davidspencer6174]

There are some examples of strong players trying to castle illegally. See Kindermann-Korchnoi 1995, or Repetto-Reti 1925.

[gcp]

I've never seen a master game where the king returned to its original square

That's because the master knows the rules (usually!) and knows there is no point in returning, on the contrary, you want to run to the normal castled position of the king, not the center.

If the computer doesn't know castling would be illegal, it will return to the original square.

[Error323]

I'm gonna pick this up to combat bias in winning statistics as observerd here: http://162.217.248.187/stats (w, b, d) = white, black, draw game ending percentages.

[jkiliani]

It's definitely a good idea, since implementing a 4-fold symmetry would also give Leela Chess non-deterministic behaviour without Dirichlet noise or temperature, like for Leela Zero. Are you still training another net in the meantime to see if the issue persists? (and incidentally, to increase playing strength :) )

[jkiliani]

Come to think of it, is castling actually a problem? If there are neural network input planes for castling, does this alone not ensure that the boards are still represented correctly even after symmetries are applied ?

[Error323]

I understand horizontal flipping (mirror along the vertical axis), but vertical flipping I don't yet. Given that these are our input planes:

    // 120 input channels
    // 14 * (6 us, 6 them, 2 reps)
    // 4 castling (us_oo, us_ooo, them_oo, them_ooo)
    // 1 color
    // 1 rule50_count
    // 1 move_count
    // 1 unused at end to pad it out.

How would augmentation work for a vertical flip. Let's say white made 1 move and then we augment. Wouldn't that mess up the move_count?

Come to think of it, is castling actually a problem? If there are neural network input planes for castling, does this alone not ensure that the boards are still represented correctly even after symmetries are applied ?

@jkiliani I think so!

[jkiliani]

Would vertical flipping not mean mirror along the axis between 4th and 5th row, applied simultaneously to a color switch? The side to move would be preserved. This would simply lead to the net being trained on a number of very early game positions that don't appear in practise, but for all later opening positions and midgame, it would generalise its knowledge.

About the move count, at the moment the net "knows" that even move counts means white to move, odd means black to move. This information would be lost with the color switching, but does that knowledge help play in any way?

[Error323]

This is more difficult than originally thought. Applying the symmetries to the boards also requires us to apply them to the move probabilities. In go this is a 1 to 1 mapping, but for chess with our compound action space this is more tricky. I'm gonna let this be for now and revisit once online training is solid.

[brianprichardson]

BTW: Zeta36/chess-alpha-zero does it, albeit in Python

[Akababa]

BTW this is where it happens in the Python version: https://github.com/Zeta36/chess-alpha-zero/blob/master/src/chess_zero/config.py#L185

I think it's not too difficult but potentially error-prone if not tested.

[CMCanavessi]

I've never seen a master game where the king returned to its original square and later had an "opportunity" to castle and the illegal castling move was a good move.

https://www.youtube.com/watch?v=sMTZwaMXc3g

[Error323]

Ok so having thought about this some more. I'm afraid we don't get a lot of symmetries after all.

Top bottom swap: We don't have the policy probabilities of the other side. So this is not possible.

Left right swap: I can only see the left/right swap when castling is no longer possible for both players. The position is just different in any other case and the symmetry does not hold.

I wonder if it's worth the effort now. We see castling is barely performed in the stats.

[Uriopass]

We see castling is barely performed in the stats.

Well.. Both side castle probability is now around 14% of both side castles from ID 33. This is not much but it's going up!

[alreadydone]

I think fixing the side to move on the bottom indeed breaks the top-bottom symmetry, unless you introduce a side-to-move input plane with 0 or 1 representing top or bottom side to move (to replace the color plane; you already used the color symmetry and that made the color plane redundant). When you flip the board, you should then change the side-to-move plane, not the color plane; the order of the queen/knight move output planes also need to be permuted. Likewise, you won't have left/right symmetry for all positions unless you introduce four additional input planes for castling rights (ooo with king moving right and oo with king moving left).

[jkiliani]

About left-right symmetry: What is problematic about training swapping a position where castling IS possible, while retaining the castling input planes just as they are? I.e., you train the net for the starting position also on the (impossible) situation where the white king was on D1 and was allowed a short castle to B1 and a long castle to F1. While that is never allowed in real games, will it actually hurt the network generalisation to train on these positions? If the white king was indeed moved to D1 in the game, the network would see that the castling input planes are broken so it could not actually do what it was trained on, but the training even on such position could easily help generalisation.

About top-bottom symmetry: For this I thought this would also be possible if you don't apply the symmetry by itself, but simultaneously with a color switch. I.e. you train a position where white is to move by mirroring along the top-bottom axis, switching the colours of all pieces, and switching the side the move all at the same time. While for the starting position, you end up training the net on the impossible hypothetical situation where black has the first move, such positions rapidly become possible in the opening i.e. if the game goes like 1.e3 e5 2.e4. The position reached here is equivalent to 1.e4 e5, but with white passing the first move on to black. Consequently, it would be logical to train on such positions as well.

I think @alreadydone has the same basic idea here, but I disagree about the necessity for additional input planes. As long as both castles with the king positions switched are treated symmetrically I think you should be fine.

Note that with both symmetries, you would be training the net on a number of positions that are either unlikely (for the top-bottom symmetry) or impossible (for left-right symmetry with castling rights) to occur in real games, but the input planes already ensure that the net could see that and would treat those cases as "what if" anyway.

[alreadydone]

Now after your clarification I think it's unnecessary to introduce additional castling planes and what you said would work just fine. Basically you use the same input plane for two purposes; it's not clear to me whether using the same plane for castlings in the same direction is better, or for castlings of the same length. With the latter you won't need to change the castling planes when you do left-right flip.

However for top-bottom symmetry I stand by my point: notice that the input planes for pieces are for "us" and "them", which I understand as the side to move and the the other side. As of now the network probably doesn't have an absolute notion of black vs. white; although the color plane hasn't been removed it's probably not used since it's not needed; I wonder how close to zero those weights are. The network always thinks it's playing for the bottom side, but it also anticipates the opponent's move from the top side..If you replace the color plane with the side-to-move plane (top or down, not black or white), the network could potentially be trained to transfer its ability to act like it's playing for the top side when the side-to-move plane says "top". The weights can be initialized to 0 plus small noise; it should be trivial to modify net2net to support adding input features.

[alreadydone]

Side question, just curious: is castling implemented as the rook's move or the king's move in the output planes? This isn't clear in the AZ paper. [Edit: OK never mind, it seems #47 there aren't any output planes, just a vector of size 1924. Probably we don't need 2 more for the hypothetical castling moves?]