Library · 2. Core Claims · mark G

The parity rule

Claim

Lattice points alternate between circles and diamonds; which parity holds the circles is a convention this project has not yet fixed.

Construction

Index the lattice so the point at (i, j) sits at (i·s, j·s) with s = r√2. One step in either axis direction crosses from a circle to a diamond or back. That alternation is forced by the geometry: circle centres and diamond centres interleave, and no two circles are adjacent.

What is not forced is where the origin goes. Put a circle at (0, 0) and circles are the even cells; put a diamond there and they are the odd ones.

Fig. 1 — the alternation is settled; which parity is which is not.

Fig. 2 — the same lattice under both conventions, drawn alike: circles on even cells at the left, on odd cells at the right. A dot marks (0,0) in each. Neither is marked correct, because the project's files disagree

Proof

The alternation is not in doubt. Any two adjacent lattice points are s apart, and by Claim F that is exactly the circle-to-diamond distance; two circle centres are never s apart, the nearest same-type spacing being 2s. Adjacency therefore always changes type, which is a bipartition by the parity of i + j.

Which half of the bipartition holds the circles is a choice of origin, not a theorem.

Why this page is contested

The project's own files disagree, and they split two against two.

Circle when i + j is odd

The Starting Kit's standing context block states it in those words. The board tool hard-codes the same convention: const isCircle = (u,v) => ((u+v) & 1) === 1;

Circle when i + j is even

The combination-shapes technical reference opens with the opposite: circles on even nodes, diamonds on odd. The Library handoff brief is reported to say the same, but that brief is not among the files on hand — what survives of it is a second-hand note recording the disagreement.

Both conventions are internally consistent. They differ only in where the origin was dropped, and this page does not choose between them.

On the files actually in hand the count is two to one for odd, not an even split, and one of the two is executable: a tool and a dataset disagree, so the problem is already live rather than merely editorial. Any enumerator or pattern routine that names cells by coordinate will read one convention and produce mirrored output under the other.

Note

This is the one claim on this shelf that is a decision rather than a discovery. Worth saying so plainly, and worth saying which way you went and why.

Open questions

Which convention becomes canonical. Until it is chosen, every coordinate-named dataset inherits the ambiguity.
Which files need correcting once it is. On current evidence that is two files whichever way the ruling goes.
Whether the library should carry an origin-free statement of the rule instead, and leave parity to each tool.

Checks

What	How	Source
The alternation itself	No two adjacent cells share a type, on any drawing of any board	reference/geometry-constants.md
Convention: odd = circle	Stated in the standing context block	Nuna-Starting-Kit (1).md
Convention: odd = circle	`((u+v) & 1) === 1`, hard-coded	nuna-board (2).html
Convention: even = circle	“Circles live on even nodes (x+y even)”	nuna-combination-shapes-reference.md
The dispute, reported	“The Starting Kit says odd; the handoff brief says even” — the brief itself is not on file	START-HERE.md