![]() StartingPoints Referenced by
|
Euclidean Go / Discussion
Sub-page of EuclideanGo
Term "live" should be changed
Would a dango live? (Discussion with rubilia by mail, partly in German)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.
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.
Die auf gruppen bezogene regelformulierung finde ich als definition allerdings eleganter, da ja gruppen die eigentlichen einheiten sind, in denen gelebt oder gestorben wird. :)
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.
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 "natural" symmetric possiblility, but it's flawy in another way - see remark B in the pic below), 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's somewhat tempting 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:
This way, we will be independent of the actual implementation of the display.
Robert's commentsRobert Pauli: Halo[1], Sebastian ;-)
% this links I see
(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! :-)) This is a copy of the living page "Euclidean Go / Discussion" at Sensei's Library. ![]() |