Euclidean Go / Discussion

Sub-page of EuclideanGo

Table of contents

Term "live" should be changed

  • (rubilia said:) Another issue is if we shouldn't rather talk of being "breathing" here than of being "alive", since the latter already has at least two other meanings. To clearly distinguish between them verbally is supposed to facilitate future discussions of e. g. life/death problems.
  • (Robert Pauli said:) Life shouldn't be confused with having liberties (I even go as far as separating it from seki :-).
  • (S:) You are both right. I'll change it to having liberties or reach white, in analogy to NZ rules or TrompTaylorRules.

Would a dango live? (Discussion with rubilia by mail, partly in German)

rubilia criticized the following definition:

A red halo (and all its red points) lives if at least one point on its perimeter is either
(1) white
(2a) red and
(2b) alive.

I think this definition is not quite what it intends to be, since it mistakenly allows to regard a completely enclosed red dango without any eye as alive. Apparently, the recent discussion took another way, but to my view, it's better to still deal with the term "connected" (which should mean having at least one common red point), and then to apply the "white point" life criteria to the entire connected set.

Für jede rote scheibe im angehängten bild trifft das kriterium (2a) zu, wie am beispiel des pink markierten bogens gezeigt. Damit hängt ihr status von dem ihrer nachbarscheiben ab, für die wiederum dasselbe gilt. Anhand dieser definition lässt sich also nicht entscheiden, welche der annahmen

"die rote formation lebt (bzw. atmet)"


"die rote formation lebt nicht (bzw. wird gerade geschlagen)"

stimmt - keine von beiden führt zu einem widerspruch.

Sebastian: I see your point - maybe i went too far when i strove for simplicity. I should add that by default a halo does not live.

Statt meiner vorgeschlagenen statusdefinition für ganze gruppen kann man natürlich ebensogut in zwei schritten zunächst diejenigen scheiben für lebendig (bzw. atmend) erklären, die selbst mindestens einen atempunkt (kontakt mit weiss) besitzen, und dann rekursiv alle damit verbundenen scheiben. So wäre gesichert, dass in jeder lebenden gruppe mindestens eine scheibe nach kriterium (1) und damit selbständig (unabhängig von seinen nachbarn) atmet. Ich vermute mal, als algorithmus ist dieser weg gut geeignet.

Sebastian: My rules are actually what i use in Miniban. (Of course, it takes a bit more text in the program, including the initialization alive=False.)

Die auf gruppen bezogene regelformulierung finde ich als definition allerdings eleganter, da ja gruppen die eigentlichen einheiten sind, in denen gelebt oder gestorben wird. :)

Sebastian: I hope by "group based rule" you mean "connection based rule" - groups are too cumbersome to identify to use them for unambiguous rules (think of seki situations, for instance).

If you mean "connection based rule", then i have to admit, you have both my favorite rules - NZ rules and TrompTaylorRules - on your side. I was fascinated by RobertPauli's wording which on the face of it got rid of the term "connection" - however, basically, he just replaced it with "could be touched by a new stone". So I guess we can use NZ rules or TrompTaylorRules.

rubilia: Right. I was pretty aware of this flaw when using the term "group" here. (Although there is no problem with sekis, which are just one form of life.) "Group" is a rather ambituous term in deed, and I think it actually should be replaced by "chain" whenever referring to a single connected set of stones - I just hesistated to choose yet another less popular word (beside "breathing" instead of (one meaning of) "alive"). Maybe it's better to do so, however. Also we can use "connected sets of stones" without introducing any destinct term, of course. (But, to keep things straight: The subject of being breathing or captured aren't connections but either stones or chains.)

Sebastian: This is not just a flaw; it is a completely different concept. You use groups because, as you say they are the natural thing to look at, because stones live and die as groups. If you replace it with any other concept, such as “chain”, then your basic motivation falls apart. I don’t see any advantage in introducing a concept such as “chain” or “string” into the rules.

rubilia: No, no, no! By "group" I am referring here to what also could be called "chain"! That's the "unit" of being alive or dead - at least with a symmetrical chain-forming connection rule. The other, often used meaning of "group" as a set of chains which live together is yet a different thing and surely not a matter of rules but of basic game analysing skills. (Whilst "stone" is a superfluosly detailed unit when talking about life/death in common Go, "group" in this meaning is too imprecise, since easily e. g. just 2 out of 7 chains forming a particular group can die. However, with asymmetrical connections, even "chain" is not detailed enough.) - Btw, as far as I can see, the terms "is connected to" and "can be touched by" are equivalent by (our currently assumed) definition, so either of them is enough to care about. Both are applied to empty as well as to friendly stones. Which one to use seems just a matter of favor to me.

One issue I was NOT aware of, are the implications of asymmetry of connections. If we don't change the connection definition (there also is a tempting symmetric possiblility - see remark B in the pic below -, but it's flawy in another way), there might be sets of stones which, although looking like it, are no single destinct group, but several subgroups, matrjoshka-like containing each other. Considering this, a stone-wise two step recursive definition like Robert Pauli's one looks the better choice to me, too.

Although it'd be nice to make the "connected to" relation symmetrical, I prefer the definition based on "can be touched by a (new) stone", because, to any stone, to breath directly should work the same way as to breath from a nearby already breathing stone. If we allowed halos to be connected by sharing any one-colored points, that principle would either have to been broken or result in every halo being alive because of sharing the centre point with white/empty. Hence breathing should be possible through a halo's own perimeter only.

How to display with accuracy? (from rubilia by email, partly German)

Ich habe mir ein paar kleinigkeiten zur grafik überlegt, erstmal unabhängig vom kommunikationsweg, über den man das ganze online spielen könnte. Anders als im kontinuierlichen (d. h. reellen) grenzfall, werden wir für praktische zwecke wohl rationale koordinaten verwenden. Ist es trotzdem möglich, das spiel regelkonsistent darzustellen, so dass auch beim hineinzoomen alles stimmt, oder müssen wir uns auf grobe veranschaulichungen der dann mit anderen als grafischen mitteln festgehaltenen spieldaten beschränken? Ich denke, ersteres könnte klappen. Statt offener umgebungen liessen sich pixelscheiben verwenden, wobei der mittelpunkt im berührungsfalle unmittelbar an eine andere scheibe angrenzen, jedoch nicht auf einem fremden scheibenpunkt liegen dürfte. Schwieriger erscheint mir, die kreisähnliche form so zu gestalten, dass eine scheibe, die an einem beliebigen punkt eine andere berührt, tatsächlich noch pixelgenau bis zu fünf weitere scheiben berühren kann. Keine ahnung, ob das geht (update: yes! - more to follow soon), aber falls es klappt, kann man die gesamte spielsituation grafisch eindeutigerfassen und braucht dabei nicht mal allzu gigantische auflösungen. Die einzelnen scheiben könnten als halbtransparente ebenen in der zugreihenfolge übereinandergelegt werden. Die farben sollten aber symmetrisch gemischt werden, also von der reihenfolge unabhängig.

Sebastian: For the moment, i'd just be happy to have anything to play. I think for we can agree that two stones placed close to each other (within the accuracy of our pixels) are meant to touch, even if they are actually not geometrically touching. (Remember, this only makes a difference if the cutting stones are placed more exactly than the cut stones.)

For a later tournament implementation, i think the most straightforward way would be to distinguish between:

  1. Points entered freely in 2-dimensional space (2 freiheitsgrade): These will be stored as a pair of x,y coordinates with single precision.
  1. Points entered on a halo near its edge: The program will snap them to the edge and store their position as (a) a pointer to the first halo and (b) the angle. On zoom in, the program would refer to the primary halo to determine the secondary halo's position.

rubilia: Doesn't this result in a non-continuous game? I am not referring to the restrictions of single-precision coordinates here (which in very strong magnification could induce some errors as well) but to the snap-zone.

Sebastian: good point. I changed the wording.

  1. Points entered on an intersection of two halos: The program will snap them to the intersection point between the two perimeters and store their position as (a) a pointer to each of the halos and (b) an indication which of the two intersection points is meant (e.g. the angle or its sign).
  1. Edges and corners of board are handled analogous to the above two cases.

This way, we will be independent of the actual implementation of the display.

rubilia: Sounds good to me.

Robert's comments

Robert Pauli: Halo[1], Sebastian ;-)

  • Euclidean is misleading: no-grid go can be played on a non-Euclidean topology, for instance, a ball's surface. How about using your nice term: Halo Go.
    • (S:) Good point. When I coined it I was thinking of situations such as: How many stones does it take to surround a single stone? However, that doesn't really touch the essence of the rules; we could apply them as well on non-Euclidean surfaces.
  • Red and blue "clearly" settles sex (she / he), but colorblind may have troubles with red / purple.
  • It's virtually impossible to recognize a single white point, e.g. one between four stones in a square squeezing the space for a fifth.
    • (S:) That's a problem with any geometric construction, but not an argument against geometry. In school, we learned to make little crosses in these cases, which would be the equivalent to your conditional board shading. BTW, this distinction will appear in reality, because there are two different situations:
      • A perfect ponnuki with exactly one white point inside. (I'm too lazy to draw another picture now, so take a look at the blue stones in "The Liberties of a Free Halo" and imagine there are 4 of them.)
      • As a protection move against a cross cut, the defender will leave a tiny overlap between his stones, so there will be no white point.
  • Your pictures are great, Sebastian! (Have to dig out the links from the edit pane, however - for whatever reason Mozilla Firebird doesn't show them?)
    Especially love

Are you sure? Suppose each halo have a radius of one unit, and place halos at (0,1),(1,0),(0,-1),(-1,0),(-2,1) and (2,-1). 6 stones, and unless i'm blind, they live!

RP: Yes, found out too in the meantime :-)

  • But after all I prefer plain, half-halo-sized stones plus
    • board color darkening if no new stone fits
      • (S:) Conditional board color darkening is an interesting idea which I'd like to discuss separately when I have the time.
    • arrow drawn between two friendly stones if one (origin) shares its liberties with the other (target) (line instead double arrow, OC)

(Sebastian:) When I created this page it was primarily in order to allow a very simple rule definition that did away with the term "connection" and allow an easy, local condition that does not require a tedious fitting test. (If you ever spent time with your significant other in a boutique you know what I mean ;-) But I now think that it's six of one or half a dozen of the other. They should not be different rules, but only different perspectives. Each perspective has its specific advantages and disadvantages. The rules will look differently, but I am confident that they we can make them mean the same. (This is math - we have an advantage over international law, where you never know if the translation really means the same.) In an actual program, users should be able to display or hide each of the following elements independently:

  • Center point
  • move #
  • stone shape
  • halo (with white background) or conditional board color darkening
  • connection line/arrow
  • maybe other geometrical features, such as bisections between stones or circles of radius n*D around stones.

RP: OC, it's just a matter of how to visualize it.

[1] (S:) sic! :-))

Euclidean Go / Discussion last edited by roule on April 19, 2007 - 17:55
RecentChanges · StartingPoints · About
Edit page ·Search · Related · Page info · Latest diff
[Welcome to Sensei's Library!]
Search position
Page history
Latest page diff
Partner sites:
Go Teaching Ladder
Login / Prefs
Sensei's Library