# Cut Topology

__Keywords__: Theory

evpsych: Here is an idea for representing a fundamental aspect of a go position, but I am still working out the notation. I'm itching for comments.

My understanding of topology is that you can stretch something without changing the fundamental properties of the thing itself. There seems to be something in that with a cut. Perhaps games can be analyzed by looking only at the cuts, and by idealizing the groups being cut or doing the cutting. Then it is easier to figure out which groups need to be killed, etc.

There are 3 basic kinds of cuts: one player cuts (resulting in 3 groups), the other player cuts (resulting in 3 groups), or they both cut (resulting in 4 groups). A cut can be erased or converted to a different kind of cut by killing a group or when two groups wrap around to connect. A global position can be canonicalized into a pattern of these types of cuts to inform strategic insight about what groups are important.

We can also note the status of each group with a standard way to represent a live (or seki), dead, unsettled, or unknown-status group that is doing the cutting or being cut. For example, not shown in this diagram, circled and squared groups can mean live and dead, respectively, while unmarked groups are unsettled or unknown. (We would use a triangle for the unsettled groups if there were a triangle.)

There are a max of 4 groups per cut and 4 states per group, resulting in 4*4=16 basic patterns for a single cut. This dramatically reduces the problem space. Then, of course, we have multiple cuts on the goban.

(We could get fancier by adding more statuses (e.g. separating out seki or including the details about the ko and sente statuses) and potential connections and miai and so on, but that would probably be too complicated for most purposes. Note also that some of the cuts might share a group.)

Perhaps this idea is useful for computer go and go databases: you can search for canonical positions without worrying about the exact positions.

Perhaps it is useful here on SL, in that you can post a game diagram that shows only the cut topology. We could say "your BQM canonicalizes into this pattern with 2 cuts".

evpsych: Hmm, no comments yet. Is the explanation clear enough?

Slarty: With this exposition, I wonder about the following position (sounds like a combination of cuts? Also the degenerate case of playing inside a ponnuki to cut and capture four groups). It's probably not a blow to finding notation though. Cuts aren't moves (necessarily), but we could define a cutting function on each occupied intersection based on adjacent opposite-color groups.

The game of Go is still going to weasel its way out of being described this way ("oh, but this group has five liberties, and can get 2 more based on twenty permutations"), but there may be some nice applications at some point. Time for extensive back of the envelope calculations I guess?? I'll start. We have 16 states per cut (either formulation) and a cut lives on one of up to 361 points. How many cuts would be reasonable to work with in a computer? That is, for what n can we catalog all positions of up to n cuts? It depends a lot on any subsequent computation, but based on what I'd care to work with (shreds of experience) and a check on chess endgame database progress at the non-supercomputer level, I'm picking "several trillions" as a rough size of a reasonable space or database these days). Probably conservative if there's a reason to pursue results. Anyhow, assuming some efficiencies (in infrequent cut states, uninteresting locations, symmetry) we could only brute force n=4. I guess that's not bad for Go. In local positions this is probably all that's needed to catalog beginnings of fights and be able to say something interesting, eventually. There's always potential for an algorithmic technique like monte carlo to mine something out of it. I don't know, I'm not responsible for finding a good purpose :) Evpsych's brainchild.