just had a game where leela was not able to win with KQ vs K (vs a relatively weak engine), but instead ended the game by allowing a 3-fold. This was with the best network so far and 2000 playouts. I don't have the pgn anymore.
vondele
All 6 comments
In all the learning data used for training this network, do the chess engines typically resign? If so, the problem could be that the neural network just hasn't seen how to reliably mate with sufficient material. Reinforcement learning should definitely solve this in any case...
jkiliani
on 10 Feb 2018
I believe the training data is human games, with players above 2000 ELO, and they do indeed typically resign. According to a grep I just did on the KingBase PGN, only 1% of the games that aren't drawn are won by checkmate.
FWIW, from my own experience, Leela with 8K playouts can win KQ vs K, but not KR vs K.
evalon32
on 10 Feb 2018
Hmmm I don't think this is an issue. The dataset used is a subset of KingBase with 1.5M games (500K black, white and draw). These are obvious holes in the NN policy that will surely get resolved during selfplay, as @jkiliani said.
Error323
on 11 Feb 2018
Here's something that might be an issue (?)
TTable uses a position hash that doesn't take repetitions into account. Thus, when visiting a node where the game is drawn by repetition, its evaluation is shared with the node where the position first occurred. That doesn't seem right.
(Note, there's code in UCTSearch::think() to "Clear the TTable for any positions in our history if we have a repetition," but I don't think that helps with repetitions that occur inside the search tree.)
evalon32
on 12 Feb 2018
LZ has removed TTable completely. Instead NNCache was modified to use a position hash, so positions reached by transposition the NNCache and we save time that way. The hash understands positions with different simple-ko states are different. But it doesn't check for super-ko, which is equivalent to repetitions for chess. You could probably do something similar though.
The original TTable code doesn't work well with UCTSearch because positions evaluations rely on sampling the evals of many positions in a certain order and propagating that information back up the tree.
Edit: here is the LZ discussion https://github.com/gcp/leela-zero/pull/662
killerducky
on 12 Feb 2018
@Error323 got rid of the TTable a while back -- should be good now.
glinscott
on 24 Mar 2018
Related issues
djinnome
路
16Comments
Error323
路
15Comments
Ilis
路
14Comments
ThomasCabaret
路
5Comments
AscendChina
路
7Comments
Most helpful comment
Here's something that might be an issue (?)
TTable uses a position hash that doesn't take repetitions into account. Thus, when visiting a node where the game is drawn by repetition, its evaluation is shared with the node where the position first occurred. That doesn't seem right.
(Note, there's code in UCTSearch::think() to "Clear the TTable for any positions in our history if we have a repetition," but I don't think that helps with repetitions that occur inside the search tree.)