Why D8 is suggested to be alive by autoscorer?
Thats a great question ^^
It shouldn’t be, no idea why its marked as such >___>
What happens after Black C4? Seems that White collapses. In cases like this, it is known that the current Autoscore makes some markings that may surprise the players.
I think this behavior is very wrong. This makes autoscorer a sort of legally cheating tool. Autoscorer must not take into account possibilities for future moves. It must only count enclosed areas and determine seki. But no more.
P. S. in that case (assume it is legal to make hint by AS) white should be marked dead ![]()
Might be a good test case for Current autoscore failures (2025)
Yeah, and this is a weird one since “estimate score” doesn’t ever show that stone alive. What is anoek’s algorithm doing??
Autoscorer must not take into account possibilities for future moves.
This would lead to even worse scorings:
For example, on a 3x3 board, after
black A1 ​ , ​ white B1 ​ , ​ black C1 ​ , ​ white B2 ​ ,
black A3 ​ , ​ white B3 ​ , ​ black C3 ​ , ​ pass ​ , ​ pass ​ ​ ​ ,
+-------+
| # O # | # = black stone
| - O - |
| # O # | O = white stone
+-------+
if one doesn’t take into account the possibilities of ​ ​ ​ ​ ​ ​ ​ white A2 ​ and ​ white C2 ​ ​ ​ ,
then Black’s stones are alive because White can’t capture them.
That’s not how it works. In your example white has 2 eyes.
This is very subtle. I have a different example here for understanding Example
Here is correct auto score result
But if we take into account the possibilities for future white invasion we got something like this
We must not do this.
In this example neither side has two eyes without future moves.
In 9x9? Yes. As I said it is subtle.
In this example it is obvious that black and white both have indisputable territory. If both players passed they have a consensus on it. I think it doesn’t matter whether they right or wrong. Katago thinks they are wrong. But does it matter?
In this case Katago won’t mark any stones dead so there should be no problem with the result. What other tool do we have to determine dead/alive status? Even if it’s “obvious” to us in many cases, it still depends on visualizing how you would continue playing, doesn’t it?
Autoscorer must not signal to players about unobvious possibility to kill stones. It is just a tool to help players mark their territory and dead stones. It must not run any sophisticated analysis.
It is not trivial to write an algorithm that agrees with the players about what is obvious and what is nonobvious. Especially given that the players in question could have a very wide range of skill levels.
The purist interpretation would be to simply have no autoscore, and all dead stones must be marked manually. But people like the convenience of autoscore, and there are the bots to consider as well.
Exactly what I said in another similar thread.
All the trouble come from bots integration. So one solution is offer manual counting to the player in bot games. Trust him or put away bots games from the rating system.
Counting the game is a full part of it, with all the acceptance involved by both players. I admit some tools being relevant to ease the process like predetermination of boundaries, keeping track of komi and prisoners…. But all under the ability to be modified by the players.
It it seriously tempting to remove bots from rated games. The hassles they create!
But imagine the outcry… bots are needed to make sure we have the opportunity to play a rated game at any time (irrespective of other player presence) and for people to get a rank.
These are darn solid reasons to keep ranked bot games.
Well then players should accept failures from the automated system. Or give them access with trust to the manual scoring.
Autoscorer must not take into account possibilities for future moves. It must only count enclosed areas and determine seki. But no more.
I’m curious about this. I think this only works if players are responsible for all dead stone marking, and I think OGS devs have already indicated (for not unreasonable reasons) that this is not an option on the table.
If there is any automated determination of life and death, and we want that determination to be even remotely accurate, then it seems like it has to take into account future moves. Otherwise, how is one to distinguish these situations?
A - Dead, despite black having fully surrounded two points
B - Dead, despite black having fully surrounded four points…. but if this shape were left as it stands on a beginner game, I would guess it’s likely that the players think it’s alive? Should autoscoring change its behavior based on the ranks of the players in the game?
C - Alive, despite black also having fully surrounded only four points. Same number of points, different status. The only thing that distinguishes this from case B is the shape and the effect that shape has on the possibilities for future moves.
D - Alive. But note that if we shifted this shape down one space, so that the rectangle 6 was adjacent to the corner, it becomes unsettled!
Basically, as long as making the players solely responsible for marking is not on the table, the problem of marking in a “human-intended” way is probably impossible to solve fully, in the worst case you have cases like B where what the players intended probably varies by rank even for an identical position on the board. We can just try to get incrementally better/worse heuristics, which @Feijoa and others have contributed a lot to and @anoek has also evidently spent time in the past improving via an entirely different non-public algorithm. In any case documenting examples of weird behavior is probably useful groundwork in case renewed efforts are ever made in the future to iterate on things some more.
Well, mostly it’s just using the excellent GitHub - lightvector/goscorer: Territory scoring in Go with seki detection ![]()
We do have a pass which consults katago for the state of stones but also does a pass to ignore some of the marked stones for various conditions where we believe the humans intended the stones to be left alive, so I reckon it’s more than that.
I don’t consider anything propriety about any of that or anything, it’s just integrated into the back end a bit, but maybe it’s worth breaking out into a smaller stand alone testable thing if you’re interested in it.
Yes I know and I know what some wants, the use of bots etc …
That doesn’t change my mind that in regular games, the manual stay as the best. Because as I said counting is fully included in a game of go. I hate that a game is wrong counted because the program can’t do it but not only. I have when the AI has a deeper view too, making both of the players feeling bad. As long as it is possible I’m asking to the games being counted “manually”.




