I'm not asking for a critique of the game overall. (You're welcome to comment, but it was a kind of mindless game against the computer and my moves weren't considered very hard.)

Anyway, at the end, the game came down to a huge capturing race. It would have ended in seki, but then black would only be about 6.5 points up. GnuGo usually only resigns when you're winning by 30 or more points, and the computer surprised my by resigning.

What do you think? Was there some way for black to actually win the capturing race that I didn't see, or did GnuGo just unusually resign a close game?

The result of the race is seki and black will win by a few points. The game is close, but white cannot win.

_________________
"You have to walk before you can run. Black 1 was a walking move.
I blushed inwardly to recall the ignorant thoughts that had gone through
my mind before, when I had not realized the true worth of Black 1."
-Kageyama Toshiro on proper moves

Perhaps the programme missed the move at D15.

By the way: If White had played at E15 with her move 232, she would have won the Semeai.

_________________
The really most difficult Go problem ever: https://igohatsuyoron120.de/index.htm
Igo Hatsuyōron #120 (really solved by KataGo)

Okay, thanks!



Heh, if it wasn't a computer, I'd say it saw that too late and resigned in disgust.

Well, not only humans and computers have their special feelings when it comes to losing too many games. Let's just think of him:


Cheers,
Rainer
(GoChild GoRo with 1858171 points)

I can't believe that.

What Cassandra (and others) say is that some moves earlier white began making foolish moves which cost the semai (even after 232 black doesn't have enough liberties). At the point of the resignation, the game was hopeless for white.

Please note that white doesn't have to save every last one of the stones of that group if the black group is killed. White kept surrendering liberties instead of connecting in a way to maximize liberties and that's why the semai was lost. Even if white loses the tail of that group (but wins the semai) white wins the game.

OK, some questions. At what strength level was gnugo supposedly playing at on what hardware. Important for folks to realize that the play of the MCTS algorithm will be erratic below a certain level.

It was Gno Go 3.7 on a 2.26 ghz Mac. Not sure what the skill level is, but checking the preferences, it is set for 'fast.' I suppose I'd better bump it down to a slower level.

gnu go doesn't use MCTS. At least not until now, but it seems like they have included it into the latest version:

GNU Go 3.8 can play 9x9 Go with the option ‘--monte-carlo’ using the UCT algorithm.
Only for 9x9, though.

And without MC, I'm not even sure that gnu go's strength scales with processing power, though it probably does to some extent.

Correct --- while a program not using a MCTS algorithm might scale somewhat according to time/processor power, that would at worst be linear. No falling off the cliff like a MCTS program given inadequate resources tends to do.

However, here we need to question the overall strength of the program and whether it has specific code to deal with precisely this situation (a very large semai). If it plays locally to conserve points that could be the explanation as correct play for white was to connect in such a way as to maximize liberties at the cost of a few unimportant points.

On the contrary. W does win after the 4 stones at D14 are captured. B cannot save them.

_________________
Still officially AGA 5d but I play so irregularly these days that I am probably only 3d or 4d over the board (but hopefully still 5d in terms of knowledge, theory and the ability to contribute).