Table of contents |
rubilia criticized the following definition:
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)"
und
"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.
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:
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.
This way, we will be independent of the actual implementation of the display.
rubilia: Sounds good to me.
Robert Pauli: Halo[1], Sebastian ;-)
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 :-)
(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:
RP: OC, it's just a matter of how to visualize it.
[1] (S:) sic! :-))