Apparently, TB thought the drawing line was winning, which would explain why it played T6 instead of |35.u5 36.w7 37.p8 38.q9 39.m6 40.n5 41.l8 42.l4 43.n7 44.r5 45.q6 46.q3 47.s5 48.t4 49.t3 50.s6 51.t8 52.r7 53.s7

So, I got lucky. Once this bug is fixed, I won't be able to hustle a draw any more. Please correct me if I am wrong!

Not necessarily true, you may still be able to snarf lots of draws. The neural net doesn't really understand draws that well as we have seen. The code which knows about draws is sort of the "scaffolding" that interfaces between the lg server and the neural net.

It's a bit schizophrenic: the neural net decides what moves to make (except for the 1st move and the swap option), and the scaffolding part decides whether to accept the draw offer.

Will try to come up with some analysis soon.

OK thanks.One question for your analysis is: in this game, after move 34, the neural net still thinks T6 is just as good as U5? And separately, would you have to retrain it from scratch to make it understand draws better?

I should also mention that 29.p12 was just an amazing move by TwixtBot. It covers all my threats perfectly, or generates unstoppable threats, whichever way you want to look at it. Of course, that means its earlier moves such as 13.l9 were even more amazing, because it judged that my M19 did not need to be directly blocked, and it would seem this judgement was correct!

I agree. I was amazed by 29.p12 as well. It makes me wonder how to clue oneself in to such a move.

I'm probably missing something obvious, but what if |36.r5?

Eh, I am missing something obvious. Never mind! After |36.r5 37.r7 you can re-establish the double threat a couple of times, but then it all falls apart.

It's a bit hard to understand what TB thinks is going on, but when it plays itself, after u5:
|35.u5 36.w7 37.p8 38.q9 39.n9 40.n8 41.o6 42.m9 43.h8 44.g6 45.f7 46.f4 47.j5 48.k5 49.d6 50.o20 51.l20 52.l21 53.h19 54.g15 55.k22 56.d3 57.d2 58.b4 59.h6 60.i4 61.h4 62.g3 63.f3
It evaluates the position after w7 as -0.826 for black. Meanwhile after t6:
|36.w9 37.p8 38.q10 39.n9 40.n8 41.k7 42.l5 43.o7 44.o22 45.o23 46.o20 47.l20 48.l21 49.k22 50.k23 51.j24 52.o6 53.j5 54.j4 55.q6 56.m9 57.e9 58.q5 59.e5 60.i10 61.h12 62.f4 63.g4 64.d5 65.c6 66.f8 67.g8 68.h13 69.g14 70.i11 71.i15 72.i14 73.k16 74.d9 75.c10 76.g12 77.e13 78.b10 79.e7 80.h3 81.d4
and it evaluates the position after w9 as -0.828 for black.

Since it is playing for White, you would expect it to prefer +0.828 to +0.826, but the difference is that those evaluations I quoted were for a full search, whereas when it is deciding between t6 and u5, it gets at most half a search for each, so it's easy to imagine that making up the 0.002 difference.

w7 and w9 are approximately equal, so move 40 appears to be where it diverges from David's actual line.

How to teach the net to learn more about draws is an interesting question. Some ideas which might work; simply need a bigger net (all the "brains" of the net are taken up with the 99% of the games that lead to wins so it has no capacity to spare for the rare case); seed the training data with more drawn games [i.e. when a training game ends up as a win, throw it out with probability 75%, and now you'll have ~1 draw for each 24 decisive game rather than ~1 draw for ~99 decisive games]. Yet another idea would be to add some human coded features: For example, shortest path to victory assuming opponent passes. After |46.o8, white needs 7 pegs, for example o24,p22,n21,i7,h5,g3,f1. If what the net seems to think is connected from p8, it would "expect" q6-p4-q2-o1 to also be a minimal path. But when it plays one of those moves and sees the shortest path doesn't change, that might be enough to teach it that the p8 peg isn't really part of a winning bridge.

Now that I think about it, the best way to teach about draws is to have two score outputs. The current net has one score output, a value from +1 to -1, with draws scored as 0. A drawish position will pull that towards 0, of course, but not very hard. If there was p_win and p_draw, then it would naturally put high values into p_draw.

I disagree with the bot's analysis. After |35.u5 36.w7 37.p8 38.q9 39.n9 40.n8 is not black's best reply. Instead 40.m9 41.k7 42.k6 43.l8 44.l11 leads to the same drawing pattern that happened in the game. White could have won cleanly with 39.m6 40.n5 41.l8 42.l4 43.n7 44.r5 45.q6 46.q3 47.s5 48.t4 49.t3 50.s6 51.t8 52.r7 53.s7 which is the analysis I posted in the very first comment here. But apparently, the bot regards the drawing line as a win for white, so it doesn't bother to look further. This is something the bot must have learned during its training. I believe, if you go over the games it played against itself in training, there will be games where the losing side didn't try for a draw because it believed that draw was a win for the side with groups close together which cross links with each other but are not actually connected. This is TwixtBot's biggest fflaw IMO. If you could provide us with the moves of some of these self-play games, I bet we could find examples to demonstrate what I am talking about. In fact, I am surprised any of its games turned into draws, based on the analysis it provides for this game.

Oh, I believe you, it's just not so straightforward a problem to fix. I will try my final idea at some point. It definitely does stumble into draws during self-play.