Stone removal and scoring updates

That would be ideal but I would agree with @hexahedron that at some point you need to compromise.

Is there even any online server that is fully compliant with Japanese rules? Seems to be such a painful ruleset…

3 Likes

It’s probably why pandanet has basically completely manual stone markings. KGS has some additional seki stuff I suppose.

That looks extremely wrong, I’ll look into it.

3 Likes

More on open border marking.

So I tested this.

Alright, the above is still consistent with my hypothesis that it marks the boundary of the floodfill wherever there is a mismatch.

But then when I moved some stones to give black a gap as well (and a smaller closed area), I got this:

This result suprised me. Given other examples in this thread, I had somehow expected this:

2 Likes

Regarding the pink squares, my objective with those was to bring their attention to areas that have been overlooked and are not sealed but otherwise very close to being territory, but to not overwhelm the board with areas that are simply contested - they should resume the game or mark dead stones to make the area not contested in those cases.

5 Likes

OK, but the white area on the left is the same shape in my 1st image and my 2nd image and they both have a single gap at C6. Isn’t it inconsistent that white gets a warning to close a border in the 1st image, but not the 2nd?

Edit: another example

…versus…

3 Likes

Not quite. In v3, basically if they are unsettled but in a larger area surrounded by live enemy stones, they get marked dead, since that seems to reduce surprises. Anyway, I don’t know if Anoek used my method. At least the version currently on the main site seems to be doing something different.

1 Like

The algorithm works by looking at empty space and if it’s fairly weighted toward being owned by one player, we point out the spaces near the opposite color and say “hey these points here need to be sealed.” That works reasonably well when the game pretty far along, but if the game is far from over it’s not expected or intended to be particularly useful.

In your first example, the threshold was met and we figured that overall white was the intended owner and mark all the places next to black. This isn’t really “correct” since there’s a ton of space left for playing, and maybe if we were going to mark something here we’d ideally just mark C6 as needing sealing or something, but I algorithmically getting it to be that smart without a ton of special cases that don’t cause a lot of other strange issues is hard, and I don’t think particularly useful as cases like this are basically cases where the game just needs to be played more, not problems with the sealing system. Your second example the contested territory is expanded and now includes a lot of territory we would estimate would be owned for black, so the thresholds and checks are not met, hence we don’t mark anything and just leave it to the player to figure out what they want to do.

1 Like

It’s basically doing that goban/src/engine/autoscore.ts at v0.8 · online-go/goban · GitHub , probably a bit different logic in the end, but roughly the same idea.

I don’t see this as a big departure. Most servers already don’t require dame-filling, which is a departure from the rules that nontrivially affects games probably somewhere from 10x to 1000x more frequently than this rule. I’m not aware of any servers implementing some of the more unusual provisions either, such as “both players lose”.

Plus, there is already precedent on other servers for counting marked-dead stones as points in sekis in “server-style” Japanese rules. For example, KGS and CGoban have behaved this way for more than a decade, including counting 2 points but not 3 points for the 2-stone almost-fill in a seki eye. So this is also consistent with what the online Go community has had and found to work well for a long time.

A small tweak one could try is that if the territory scoring algorithm indicates that one of the marked-dead chains supplied to it is part of a seki and there are only 1 or 2 stones in that chains and it is within an eye of at most 3 spaces large, then make it so that the chains is NOT marked as dead by default, i.e. disregard and revert the AI marking in that case.

There are likely to be some side effects from doing that though - for example, it may result in the rejection of some dead markings in some cases of incomplete border closure, because the incomplete border closure results in a position as being counted as a “seki” when the entire territory that would normally easily have a group live is not counted as owned by that group. It would be up to @anoek to decide if he wants to do that. (The additional conditions for only having 1-2 stones and being within an eye of at most 3 spaces are heuristic attempts to limit these false-positive side effects, but there will still be some probably).

Although one could try this tweak to the AI-supplied default dead stone marking if okay with the side effects, I would not recommend discounting the points if the user is the one who forcibly marks the stones as dead. That would probably lead to confusing UI, and again as mentioned above there is precedent for counting the points.

5 Likes

For @shinuito 's neat example:

The dead stone markings here appear to be a point-by-point reflection of ownership prediction, and this is because after the under-the-stones these positions will indeed end up partially shared. But I think for the scoring interface one should enforce that the marking has to be the same across an entire chain.

Off the top of my head, I would guess the following would probably work reasonably as a way to adjust the default AI markings starting from a preliminary marking like this, without too many weird side effects:

  1. If a chain contains both stones marked dead and stones marked alive in the preliminary marking, mark the entire chain as alive by default.
  2. If a chain has one or more marked dead stones in the preliminary marking but is directly adjacent to an opponent chain that contains any stone marked dead in the preliminary marking, mark the entire chain as alive by default.

So for example, all of the stones in the upper left would be marked alive by default. The white square block is marked alive due to both rule 1 and rule 2, and the black B9 stone is marked alive due to rule 2.

I distinguished carefully the “preliminary marking” in rule 2, to make the behavior order-independent. i.e. even if one applies rule 1 “first” to mark the white square block as alive, rule 2 still applies to mark B9 alive.

Of course, the players could modify the marking further from there. These rules basically implement the TLDR of “aaah the AI is giving markings indicating there is under-the-stones, hands off and just let the players handle it”.

2 Likes

So I tried some positions with open border(s) that are closer to being finished, but I still have a hard time wrapping my head around some of the results.

Like this …

… versus this …

(the dead stone marking at E3 comes from autoscore, but I’m focusing more on the open border markings)

If someone asked me to explain the reasons behind those marking differences, I don’t think I could.

3 Likes

Not sure how one would codify this, but here is where i would expect pink squares on @gennan’s board, based on the the stated goal:

3 Likes

I mean, yes, I would like that too I suppose. For this example, I could think of some very simple algorithms to highlight those, but generalizing them to do good sane things for all use cases without making some weird suggestions in other cases I suspect would be more challenging.

Honestly though these contrived examples are exploring the edges of where the algorithm will even bother to try and help. I’m not sure it’s worth trying to turn them into examples of what it should and shouldn’t do, I’d rather consider real world examples of where the algorithm did something that wasn’t helpful kind of thing. I think the closest we have so far is this one:

and while I would be fine with some of the suggestions to have it presented differently, it’s much easier said than done to get an automatic way of handling all the situations in an intuitive manner to output results like are being suggested (and without inadvertently highlighting and exposing weaknesses in the overall board position). Practically speaking I think the current output for that game is fine too, while it may imply that there is a thin line that needs to be sealed where as really there are many moves to play in that areal, it at least brings attention to where they still need to play things out more.

9 Likes

This feels like a strange way to avoid just saying groups in seki are alive. If you have pretty good seki detection, and it’s marking parts of the groups in the seki as dead, override them to being alive. That seems much simpler than having edge cases where some stones of a certain length in a certain shape are alive but we’re unsure how general that would work etc. Effectively that’s what you do in scoring when you don’t remove them or rearrange the shapes - they’re not dead so they’re not removed, they’re not territory so you don’t rearrange.

I’ve really only played a handful of games overall on KGS, so maybe KGS has set some precedent for how it autoscores certain stones as dead, I don’t know.

I don’t think KGS does autoscore. As far as I remember the players mark dead groups and afterwards the seki algorithm determines which remaining living groups are in seki. The seki algorithm doesn’t decide which groups are dead/alive.

1 Like

In that case I don’t really understand this comment.

Because that sounds like it was a human decision or tradition by the players and not by KGS itself.^^

I would see literally deciding which stones are alive and dead as a much bigger departure from the rules, than dame which mostly don’t change scores or results. If it’s the case that seki algorithms and flood filling were smart enough to even remove a point or two from teire then that’s even less of a departure from the usual rules.


Apologies if this seems like too much of an edge case to fix or decide on - It’s just going to be another one of those things where players come across some weird scoring rule, probably in 9x9 more than elsewhere, and we just have to throw our hands up and say “it is how it is, I can’t explain it, don’t trust the autoscore”.

I think that comment is about how to score dead stones inside a seki (left to scoring instead of being captured before scoring, as they should be), not about adjudicating them dead. I think the players still need to do the marking of dead stones on KGS. But as you said, dead stones inside a seki should not score points under official Japanese rules, but KGS still does it (and so does @hexahedron’s version of the seki detector).

I think we should clearly distinguish group status adjudications made by autoscore (under various rule sets) from any follow-up scoring (dame) decisions made by hexahedron’s seki-detector used only under Japanese rules. As far as I understand, the seki detector only adjucates which intersections are dame, and thus should not score territory points.
Up to now, OGS players had to manually mark seki eyes as dame under Japanese rules. That won’t be necessary anymore (and perhaps not even possible) with the upcoming update.

Still, even though hexahedron’s algorithm doesn’t play a part in group status adjudications by autoscore (as far as I understand), he is interested in that as well and tried to give some advice on how autoscore might properly adjudicate group status in your example.

So he’s saying that autoscore (or the players themselves) should adjudicate group statuses in your example like this:

I suppose that also when scoring under Chinese or AGA rules, this group status adjudication would be the correct one. If one of the players disagrees with all of the stones in the top left and bottom right being alive during scoring, they should resume the game to capture.

1 Like

There is one other funny behaviour I’m noticing with respect to clicking the autoscore button:

It’ll autoscore like this, and every second click of the autoscore button is like “turning off” or “on” the autoscore in that nothing is marked dead or it reverts to this.

This then leads to some weird behaviours. For instance if one player for some reason or another clicks one of the white groups like:

then clicking the autoscore button alternates between the above and this other state:

That would seem to be the case for both players clicking the autoscore (except one time when it reset and I’m not sure why).

Maybe the autoscore button, shouldn’t alternate like this in general?

I think that’s the right answer as well, I’m adding it to our test suite and will be adjusting things to make it so.

2 Likes